In 2013, the Automated Clearing House (ACH) Security framework was established in order to protect ACH data throughout its lifecycle. This framework helped secure “protected Information” or “the non-public personal information, including financial information of a natural person used to create, or contained within, an entry and any related addenda record.” But the world has changed a lot since 2013 and in order to benefit the users and providers of the ACH, the National Clearing House Association (Nacha) continually accesses the framework to ensure the secure transmission of data, routing number validation, identify verification, fraud detection, and more.
Nacha has introduced supplemental data security requirements, which explicitly require large, non-FI Originators, Third-Party Service Providers (TPSPs), and Third-Party Senders (TPSs) to protect deposit account info by rendering it unreadable when it is stored electronically.
- Phase 1 of the Rule, which applies to ACH Originators and Third-Parties with more than 6 million ACH payments annually, is now effective on June 30, 2021
- Phase 2 of the Rule, which applies to ACH Originators and Third Parties with more than 2 million ACH payments annually, is now effective on June 30, 2022.
How are Data Security Requirements Changing?
While the current ACH requirements require some parties involved in ACH transactions to obscure account information, it does not explicitly require obscurity from non-financial institution originators, third-party service providers (TPSPs), and third-party senders (TPS). The new requirements are part of a larger project to continuously secure consumer data — no matter what technology or payment type is used.
How Can You Prepare?
The new supplemental data security are neutral to the methods/technologies/integrations that organizations use to render data or account information unreadable when stored electronically but TPSPs, non-FI originators, and TPSs should think carefully about implementing a scalable and sustainable long-term data protection solution. Some possible methods include encryption, truncation, tokenization, destruction, and having data stored, tokenized or hosted by an ODFI.
For more information on the upcoming deadline and how to prepare, check out our informative ebook: The Current State of Data Security in Payments (& How to Comply). Or check out our on-demand webinar with Nacha.
How Trustly Secures Data
Trustly customers will not have to worry about maintaining compliance. Trustly’s SOC2 certified solution helps ensure the security and integrity of data at rest and in transit. Trustly has implemented three controls relevant to the security and availability of data:
- Encryption for data at rest and in transit: All data that flows through the Trustly online banking platform is protected with TLS protocol. Personal identifiable information (PII) is encrypted at the field level on our database according to the highest industry standards.
- Split tokenization: Split tokenization is a Trustly patent pending method used to store highly sensitive information. It works by assembling bank credentials, including answers to security questions, cookies, and device fingerprints as a class object. That object is then serialized, compacted, encrypted, and split into two pieces (split tokens). This method ensures that Trustly never stores account credentials.
- Continuously updated cloud security: Our infrastructure is fully deployed on the cloud with the latest security patches — the keys on each deployment are changed multiple times a week.