Tokenized Account Numbers (TAN)

The number of financial payments that depend on the ACH and RTP networks is growing rapidly. Traditionally, these payments require knowing and holding a customer’s account and routing numbers. The storing and transfer of this sensitive information is inherently risky and increases the likelihood of financial fraud.

One solution to decrease risk is to use tokenized account numbers (TANs) to replace standard account numbers. Tokenizing account numbers is a solution gaining momentum across the industry, and several Akoya data providers support TANs.

TANs protect account numbers by replacing the actual account number with a token, a randomly generated number. The token allows you to still perform a payment without sharing the actual account numbers. The token is stored in a separate location from the actual account number and routing information, while the token-to-account mapping is stored in a secure vault.

Tokens have the same form-factor as the actual account number. The routing transit number is different, but they use the same routing transit structure and account structure. The Clearing House (TCH) launched Secure Token Exchange (STE) to tokenize account numbers in a way that does not alter existing payment authorizations.

If there is a data breach of any participant, the benefits of TANs include:

Mapping is separate and validated during payment processing. This limits the token’s value to a fraudster.
One or many tokens can be systematically turned off to mitigate risk.
Replacing tokens if necessary is more efficient and cost-effective than replacing real account numbers.

Troubleshooting TANs

As TANs are a relatively new development, you may encounter a learning curve adapting your systems that work with standard account numbers to also work with TANs.

You can determine if an account number is tokenized by looking at the response to a Payments API call. If the paymentNetworks response indicates that the identifierType is TOKENIZED_ACCOUNT_NUMBER, then the account number is tokenized. For more information, see Payments.

R04 Account not found

ACH return codes signal that an error occurred in a financial transaction. The ACH R04 error code signifies an invalid account number or account not found. Third-parties originating ACH transactions using TANs can face the potential scenario of an R04 code. It is an indication that the account number used in the Nacha (National Automated Clearing House Association) file for either the credit or debit account does not map to the physical account number or is not found anywhere in the vault at this time. A Nacha file is one of the most common types of payment files and is used to execute domestic ACH payments.

Here are four common causes for receiving an ACH R04 return code:

TAN with standard routing number or standard account with TAN routing number: The TAN is comprised of a specific tokenized account number and a specific routing number for tokenized account numbers. You can have a mismatch if you use a TAN with a routing number for standard accounts, not the correct TAN-specific routing number. You can also have a mismatch with the reverse, a standard account number with a TAN-specific routing number.
Using a former standard account number. Customers may have former standard account numbers in the system. These cannot be interchanged with the TAN account and routing number. The TAN pair must be used as provided.
Truncation of digits: The length of the TAN shared by the API can vary by institution, but is no longer than 17 digits. The first two digits are always 00. The two leading 0's may be dropped but it’s important to keep all remaining digits when generating a NACHA file. Dropping additional leading digits or trailing digits can cause the account look up to fail and result in an R04 response.
Using a disabled TAN: When an account has been removed from a consent or the consent is revoked, the associated TAN is also disabled. These errors occur both when the TAN is disabled shortly before the transaction and also when the TAN has been disabled for several months. TANs require more than a typical account verification with a “one and done” authorization. TANs require that the customer maintains an active consent with the third-party to continue to transact.

Resources

Need help?

Check out our Developer Community, or visit the Support Center in the Data Recipient Hub.

Looking for provider nuance documentation?

All provider nuance documentation is available in the Data providers section in the Data Recipient Hub.

Still stuck?

For all production issues, submit a support ticket through the Data Recipient Hub. Our support team is standing by 24/7. Questions and non-production issues will be answered during business hours.