Select Laws, Regulations, Standards, and Frameworks
Cybersecurity and Strong Authentication
NYDFS: Cybersecurity Requirements for Financial Services Companies
The NYDFS regulates approximately 1,500 banks and financial institutions. These include U.S. institutions as well as many international institutions with operations in New York.
The Cybersecurity Requirements for Financial Services Companies consists of 22 provisions that require financial services organizations to better protect data. Financial institutions must implement effective controls to prevent unauthorized access to information systems or non-public information through risk assessment, but the means by which they do so can include multi-factor authentication, biometric authentication, or risk-based authentication.
Learn more in this blog: NYDFS Cybersecurity Requirements for Financial Services Companies
PSD2: Payment Services Directive 2
The EU Payments Services Directive (PSD2) contains requirements related to Strong Customer Authentication (SCA). Financial institutions must comply with these requirements by September 2019. However, specific Payment Service Providers (PSPs) could qualify for an exceptional extension in the context of card payments for e-commerce according to a recent EBA Opinion.
These requirements include five criteria of compliance:
- Strong Authentication: Authentication must be based on two or more factors, including passwords or PIN, tokens or mobile devices, or biometrics.
- Transaction Risk Analysis: Mandates the use of transaction risk analysis to deter fraudulent payments.
- Replication Protection: PSD2 mandates the use of dedicated mobile app cloning counter-measures in applications.
- Dynamic Linking: For payment transactions, the authentication code must be dynamically linked to both the amount and payee.
- Independent Elements: Payment service providers must adopt security measures to mitigate the risk resulting from compromised mobile devices.
EU Cybersecurity Certification Framework
The new EU Cybersecurity Certification Framework, originally proposed in 2017, was developed to improve the cyber security of online services and consumer devices, including IoT devices. Once formally approved by the European Parliament, it will be published in the EU Official Journal and officially enter into force immediately. For more information, read the official press release.
Saudi Arabian Monetary Authority (SAMA)
To improve resilience against cyber threats, the Saudi Arabian Monetary Authority (SAMA) introduced the SAMA Cyber Security Framework in May 2017. This follows a global trend where government and banking industry regulators around the world are introducing cybersecurity standards and guidance.
The four key aspects of the framework include:
- Identity & access management
- Secure communication channel for online and mobile banking
- Mobile application shielding
- Fraud detection and prevention
Learn more in this blog: SAMA Cyber Security Framework Compliance
Singapore: Technology Risk Management (TRM) Guidelines & Business Continuity Management (BCM) Guidelines
The Monetary Authority of Singapore (MAS) has issued Technology Risk Management (TRM) Guidelines and Business Continuity Management (BCM) Guidelines.
The TRM Guidelines provide direction for software development security, cyber surveillance, adversarial attack simulation, and how to manage the cyber risks posed by the Internet of Things. The TRM also includes a section on the “Security of Online Financial Services”, which covers the following:
Sec.14.1.7 “Rooted or jailbroken mobile devices should be blocked from accessing the FI’s mobile applications to perform financial transactions as such devices are more susceptible to malware and security vulnerabilities.”
Sec. 14.2.1 “Multi-factor authentication should be deployed at login for online financial services to secure the customer authentication process.”
Sec. 14.2.4 “FI may apply a risk-based approach and implement appropriate risk-based or adaptive authentication that presents customers with authentication options that commensurate with the risk level of the transaction and sensitivity of the information.”
Sec. 14.2.8 “Where soft token is used for customer authentication, appropriate measures, such as verifying the identity of the customer, detecting and blocking rooted or jailbroken devices, and performing device binding, should be implemented for the soft token provisioning process.”
Sec. 14.3.1 “The FI should implement real-time fraud monitoring or surveillance systems to identify and block suspicious or fraudulent online transactions.”
PCI DSS 3.2
Payment Card Industry Data Security Standard
PCI DSS 3.2 is an information security standard for organizations that handle branded credit cards from the major card brands. It was put in place to address security threats to customer payment information. All entities involved in payment card processing must comply with PCI DSS, including acquirers, issuers, merchants, processors, and service providers. It also applies to all other entities that store, process, or transmit cardholder data.
Requirement 8.3, which became mandatory in 2018, requires organizations to incorporate multi-factor authentication for all non-console access to the cardholder data environment, as well as remote network access originating from outside the entity’s network.
SWIFT Customer Security Programme
To adapt to the changing threat environment and stay ahead of cybercriminals, SWIFT (the Society for Worldwide Interbank Financial Telecommunication) introduced the SWIFT Security Controls Framework and Customer Security Programme (CSP). For more information on how SWIFT helps to ensure the security and integrity of the systems that connect to the SWIFT network, see this blog.
Data Privacy and Protection
US: Gramm-Leach-Bliley Act
The US Federal Trade Commission (FTC) announced in March 2019 its plans to implement changes to the Safeguards Rule and Privacy Rule under the Gramm-Leach-Bliley Act. These include:
- The Safeguards Rule:
In effect since 2003, the Safeguards Rule requires financial institutions to put measures in place to keep customer information secure. Institutions are also responsible for ensuring that their affiliates and service providers safeguard customer information. (The best practice to accomplish this is by implementing multi-factor authentication.)
- The Privacy Rule:
In effect since 2000, the Privacy Rule requires a financial institution to inform customers about its information-sharing practices and allow customers to opt out of having their information shared with certain third parties.
US: HIPAA Privacy Rule
The Health Insurance Portability and Accountability Act of 1996 (HIPAA) Data Privacy Rule provides standards and guidance for the appropriate protection of patient’s medical records and personal health information. It applies to health plans, healthcare clearing houses, and healthcare providers that conduct select transactions electronically.
Our e-signature solution, OneSpan Sign, facilitates compliance with all HIPAA requirements as they apply to business associates.
US: California Consumer Privacy Act (CCPA)
The California Consumer Privacy Act is modeled off of the GDPR and seeks to protect the data of Californians. It includes many of the same tenants as GDPR, including:
- Expanded consent requirements
- Right to Access
- The Right to Be Forgotten
In addition, many states in the US are in the process of passing legislation modeled at least in part by the California Consumer Privacy Act.
US State Insurance Data Protection Laws
Several states in the US have enacted legislation to enforce multi-factor authentication (MFA) requirements for any individual accessing “nonpublic information”, including private insurance information.
- South Carolina: Act No. 171 was put into effect on January 1, 2019 requiring South Carolina licensees to implement an information security program by July 1, 2019. They must also comply with due diligence requirements for third-party service providers by July 1, 2020.
- Michigan: House Bill 6491 will take effect on January 20, 2021, requiring Michigan licensees to implement an information security program by January 20, 2022. They must also comply with due diligence requirements for third-party service providers by January 20, 2023.
- Ohio: Senate Bill 273 was put into effect on March 20, 2019 and applies to all insurers in Ohio. The bill stipulates security measures that must be put into place by March 20 of the following year.
- Mississippi: Senate Bill 2831 went into effect on July 1, 2019. Licensees are required to have MFA in place by July 1, 2020. Furthermore, they must also comply with due diligence requirements for third-party service providers by July 1, 2021.
Canada: Personal Information Protection and Electronic Documents Act (PIPEDA)
PIPEDA is the federal regulation governing the security requirements around the collection, use, and disclosure of personal information in Canada. It applies to both governmental organizations as well as private organizations that collect, use, and disclose personal information as part of doing business, such as financial institutions.
EU: The General Data Protection Regulation (GDPR)
The European Union’s General Data Protection Regulation (GDPR) applies to the data protection of personal data pertaining to all EU citizens. It applies to any company that processes or collects personal data from an EU citizen regardless of whether the organization is based in the EU, thus worldwide.
The GDPR sets out seven key principles:
- Lawfulness, fairness and transparency
- Purpose limitation
- Data minimization
- Storage limitation
- Integrity and confidentiality (security)
Under Article 32 companies considered as controllers or processors of personal data are obliged to implement appropriate technical and organizational measures to ensure a level of security appropriate to the risk.” ENISA, the European Union Agency for Network and Information Security, advises member states and private sector organizations in implementing EU legislation and as such, provides guidelines on how to take appropriate measures to comply with the GDPR.
- For access control and authentication: ENISA recommends implementing two-factor authentication in high-risk cases and in certain medium impact cases, as follows: “Two-factor authentication should preferably be used for accessing systems that process personal data. The authentication factors could be passwords, security tokens, USB sticks with a secret token, biometrics etc.”
- For mobile devices: ENISA advises that special care must be taken to ensure that business-related data is not compromised. As a result, their guideline states that “two-factor authentication should be considered for accessing mobile devices, and personal data stored at the mobile device should be encrypted.”
- For application development: ENISA recommends ensuring that personal data security is taken into consideration. During the development lifecycle, this encompasses “best practices, state of the art and well acknowledged secure development practices, frameworks or standards should be followed,” even for low risk cases. Learn more about two factor authentication in this blog.
In addition, no personal data may be processed without a lawful basis. One of those bases is “consent”. Any organization evaluating their consent policy and mechanisms to comply with the GDPR could consider the use of electronic signatures – especially when handling sensitive personal data, such as personal financial information or medical records. Electronic signatures provide a secure, auditable, and easy-to-use solution to assist in implementing technical and organizational measures in accordance GDPR. This technology is an appropriate method for data controllers to capture consent, comply with the active opt-in requirement, and demonstrate details of how consent was obtained, including what was consented to, when, and by whom. Learn more about capturing customer consent in this blog.
Chile: Law No. 19,628 on the Protection of Private Life or Personal Data Protection Law
This law defines requirements regarding the treatment of personal information in both public and private databases.
Brazil: Lei Geral de Proteção de Dados (LGPD)
Lei Geral de Proteção de Dados (LGPD) goes into effect in August 2020. The regulation includes some of the provisions of the GDPR in Europe. However, it also applies additional compliance obligations on organizations that process data or offer services to individuals in Brazil. Companies are required to acquire explicit consent from the individual before collecting data. The individual must be informed of exactly what data is being collected, the reason for its collection, and the duration it will be stored. Furthermore, when a company no longer has need of the acquired data, it must be destroyed.
Thailand: Personal Data Protection Act B.E. 2562 (2019) (PDPA)
Approved in May 2019 and set to take effect in 2020, the PDPA defines personal data as any information that can be used to identify an individual. This broad definition applies to any such data belonging to customers, employees, and companies, and the PDPA applies significant restrictions on its collection and use.
Furthermore, the PDPA provides rights to the subject of personal data similar to GDPR, such as the right of access, right of erasure, right to object, and right to data portability.
US: ESIGN Act & UETA
In the US, federal and state law gives electronic signatures the same legal status as handwritten signatures. The Federal Electronic Signatures in Global and National Commerce Act (ESIGN) gives legal recognition for electronic signatures and records to satisfy the “in writing” legal requirements for transactions, including disclosures, and permit organizations to satisfy statutory record retention requirements solely through the use of electronic records. ESIGN requires a person’s consent to conduct business electronically.
At the state level, forty-seven states, the District of Columbia, Puerto Rico, and the Virgin Islands have adopted the Uniform Electronic Transactions Act (UETA). Additionally, the federal ESIGN law provides that electronic signatures are legally enforceable for intrastate commerce and within those states that have not adopted UETA.
US: 21st Century IDEA Act
On December 20, 2018, The 21st Century Integrated Digital Experience Act (21st Century IDEA) was signed into law. It creates minimum functionality and security standards for federal agencies in the US with the goal of improving digital interactions between citizens and government. For example, it requires agencies to offer digital versions of all paper-based services and to accept electronic signatures from citizens.
Learn more in this blog.
US: Financial Industry Regulation Authority
The US FINRA Rule 4512(a)(3) (Customer Account Information) previously required brokerage firms to obtain the “wet” signature of each named, natural person authorized to exercise discretion in an account before opening the account. On April 16, 2019, the U.S. Security Exchange Commission (SEC) passed a proposed change to Rule 4512(a)(3) providing members with the option of obtaining an electronic signature in place of a wet signature.
Learn more in this blog.
US: State Remote Online Notarization Laws
Numerous states in the US have passed or are considering legislation that would empower their state notaries to perform remote online notarizations. This includes:
- Indiana SB 372 (signed into law 3/13/18; effective 7/1/19)
- Louisiana HCR 31 (introduced 4/6/18; passed House and Senate)
- Michigan H 5811 (signed into law 6/28/18; effective 3/30/19)
- Minnesota SF 893 (signed into law 5/20/18; effective 1/1/19)
- Nevada A. 413 (signed into law 6/9/17; effective 7/1/18)
- Ohio SB 263 (signed into law 12/18; effective 9/19/19)
- North Dakota HB 1110 (signed into law 3/11/19)
- South Dakota HB 1272 (signed into law 3/18/19)
- Tennessee SB 1758 (signed into law 5/15/18; effective 7/1/19)
- Texas HB 1217 (signed into law 6/1/17; effective 7/1/18)
- Kentucky SB 114 (signed into law, 3/25/19; effective 1/1/20)
Canada: Provincial Law
Similar to US UETA laws, Canadian provincial e-signature laws give electronic signatures the same legal status as handwritten signatures.
Substantially uniform electronic commerce and electronic signature laws have been enacted across Canada. All the provinces and territories have stand-alone electronic commerce statutes of general application based on model laws promulgated by the U.N. and the Uniform Law Conference of Canada (ULCC).
For example, in Ontario the Electronic Commerce Act, 2000 (ECA) addresses the use of electronic documents in commercial transactions. In a report entitled Electronic Signatures in Canadian Law, leading Canadian business law firm Stikeman Elliott LLP states, “While there are some variations, the provincial e-commerce statutes generally stipulate that signatures, documents and originals are not invalid or unenforceable by reason only of being in electronic form.”
To learn more, read the Stikeman Elliott legal guide to electronic signatures.
EU: eIDAS (Electronic IDentification and Trust Services)
The 2014 Regulation on Electronic Identification and Trust Services for Electronic Transaction in the Internal Market (eIDAS) went into effect throughout the European Union on 1 July 2016, replacing Directive 1999/93/EC on electronic signatures. Unlike the Directive, the eIDAS regulation applies equally to each EU Member State.
eIDAS facilitates cross-border recognition of e-signatures and e-identities. It also identifies three levels of e-signature: the Simple, Advanced, and Qualified E-Signature.
Learn about the legal enforceability of the three levels of e-signature in this white paper: eIDAS and E-Signature: a Legal Perspective, written by Lorna Brazell of Osborne Clarke LLP.
In Brazil, the use of electronic signatures falls into two categories:
- Technology-neutral: Brazilian law allows for an electronic signature in use cases where the type of signature is not specified by the law. In this approach, the electronic signature must ensure the integrity of the signed document and the authenticity of the authorship of the signature, but the law does not specify the technology. Freedom of form in the Brazilian law infers this technology-neutral approach.
- Technology-specific: Certain types of documents and signers require the use of a digital certificate issued to the signer by the ICP-Brasil infrastructure. This is a technology-specific system where the ICP-Brasil certificates provide a trusted third-party verification of the electronic signature. ICP-Brasil establishes the public key infrastructure for the country, which provides the necessary time-stamping and policies to create the equivalent of a Qualified Electronic Signature (QES).
Learn more in this Portuguese white paper on Electronic Signatures and the Law in Brazil, written in collaboration with Opice Blum LLP.
Law 527 of 1999 established electronic signatures as the equivalent of handwritten signatures. It gives e-signatures the same validity and legal effect as a handwritten signature, provided that the e-signature complies with the reliability requirements stated in Decree 2364 of 2012.
Learn more in this Spanish white paper on Electronic Signatures and the Law in Colombia, written in collaboration with Erick Rincon Cardenas, a partner at Rincon Cardenas & Moreno.
In 2000, the Congress of the Republic of Peru approved Law No. 27269 on Digital Signatures and Certificates, which reads as follows: “The purpose of this law is to regulate the use of e-signatures, granting them the same legal validity and effectiveness as handwritten signatures or similar which imply a declaration of will.”
Learn more in this Spanish white paper on Electronic Signatures and the Law in Peru, written in collaboration with Erick Rincon Cardenas, a partner at Rincon Cardenas & Moreno.
Australia: Electronic Transaction Act
In 1999, the Australian Parliament passed the Electronic Transactions Act, which was amended in 2011. The Electronic Transactions Act gives electronic signatures the same legal status as handwritten signatures.
According to the Australian government, “If a Commonwealth law requires you to give information in writing, provide a handwritten signature, produce a document in material form, or record or retain information, the Electronic Transactions Act means you can do these things electronically.”
Learn more in our eBook, Electronic Signatures and the Law: Global Legislation Review.
Japan: The Electronic Signatures and Certification Business Act
In effect since 2001, Japan’s Electronic Signatures and Certification Business Act recognizes the legal enforceability of two types of electronic signatures used worldwide: Advanced E-Signatures and Qualified E-Signatures.
Learn more in our eBook, Electronic Signatures and the Law: Global Legislation Review.
Singapore: Electronic Transactions Act (ETA)
Put in place in 1998, this law provides the legal foundation for electronic signatures and gives predictability and certainty to electronic contracts. According to the Government of Singapore, “In the electronic world, hand-written signatures can be replaced by digital signatures. Like written signatures, digital signatures may be used to establish the identity of a party or to make legal commitments. The Electronic Transactions Act provides for the recognition of digital signatures under Singapore law.”
Learn more in our eBook, Electronic Signatures and the Law: Global Legislation Review.
EU: PSD2: Payment Services Directive 2
Open banking promises to unlock innovation that will profoundly improve the banking experience and introduce new financial services. For example, Third Party Providers (TPPs) can provide applications that enable consumers to consult multiple bank accounts from a single application, or apps that make it easier for businesses to share data with their accountants.
Under PSD2, banks must offer an interface allowing TPPs to communicate with them. That way, if the consumer wants to use financial service providers other than the bank, these providers can gain access to the bank’s systems and serve the bank’s customers via the open communication interface.
The introduction of open APIs makes banks dependent on the security of the TPPs using these APIs. Banks should adopt a number of technical and organizational security measures to address these and other threats. In the context of open banking, banks can mitigate risk in multiple ways:
- Use transaction risk analysis
- Choose the right authentication model
- Protect the communication channel with TPPs
- Request independent security audit reports from TPPs
- Avoid security vulnerabilities in the API implementation
To learn more, read this blog on Open Banking APIs Under PSD2.
Bahrain: Central Bank of Bahrain (CBB) Rules for Open Banking
The Central Bank of Bahrain (CBB) has several rules in place regarding open banking. This includes a rule that Payment Initiation Service Providers (PISP) must have in place a strong customer authentication process. (Learn more about authentication)
The rules also imply that customers will share their login details directly with the third-party providers, rather than through a redirection-based mechanism where the customer is forwarded onto a login screen operated by their bank.
Account information service providers (AISPs) will be prohibited from accessing a customer’s information beyond that found in a designated account or from storing data for any reason other than providing the account information service “explicitly requested by the customer”.
New Zealand: Open Banking API Standards
Payments NZ is a payments industry group of banks, processors, and infrastructure providers. After a pilot lasting a year, the group published standards for APIs.
The standards are limited to APIs for payment initiation and account information services, but resemble open banking initiatives in other countries.
The New Zealand Bankers' Association said the country’s banks “fully support” the common standard.
Hong Kong: Open API Guideline for Banks
The Hong Kong Monetary Authority (HKMA) published an Open API guideline for banks and financial institutions operating in Hong Kong.
In its initial stages, the framework focuses exclusively on retail banking, but if other banks find it appropriate, HKMA encourages them to extend the standard to other business lines.
Japan: Amendments to the Banking Act
In June 2018, Japan passed amendments to their Banking Act which put in place requirements for partnerships between financial institutions and fintech payment operators.
Republic of Korea: Amendments to the Electronic Financial Transaction Act of 2007
To increase competition and innovation in the financial services and fintech sectors, the Republic of Korea amended their Electronic Financial Transaction Act. The amendments obligate Korean banks to open their payment systems to third party fintech organizations as well as other banks.
This move provides the ability for customers to access their accounts at different banks and make payments from a single application.
Canada: Open Banking Consultation
The Department of Finance Canada set up an Advisory Committee to investigate the potential for an Open Banking policy in September 2018. The committee then released a consultation paper to drive public conversation on whether open banking would provide meaningful benefits; how risks related to consumer protection, privacy, and security should be managed; and what role government should play in any implementation.
US: Open Banking API
The Financial Data Exchange (FDX) is a non-profit financial industry organization and subsidiary of the Financial Services Information Sharing and Analysis Center (FS-ISAC). Its mission is to create a common, interoperable, and royalty-free standard that delivers to businesses and consumers secure access to their own financial data.
The National Digital Office (CEDN), in collaboration with the National Banking and Securities Commission (CNBV), C Minds, the Open Data Institute, and Dev.f led an industry-wide effort to develop an open banking standard. The standard focused in particular on the standardization of APIs and open data through the development of a pilot.
The pilot, branded LABORA, sought to confirm the viability of the implementation of an open banking standard in Mexico. It tested three to four endpoints and carried out a controlled implementation with expert users to evaluate the usability, interoperability, and value of existing APIs as well as the implementation of endpoints defined by the standard.
The information contained on this page is for information purposes only, provided as is as of the date of publication, and should not be relied upon as legal advice or to determine how the law applies to your business or organization. It does not constitute legal advice. We recommend that you seek guidance from your legal counsel with regard to law applying specifically to your business or organization and how to ensure compliance.