Reduce fraud risk with tokenized account numbers

Written by Florian Wahl | May 02, 2022

Summary:

The growth of digital payments has led to the broad sharing of private customer account information typically held by financial institutions, which increases the risk of fraud.
The U.S. has various payment rails (i.e., networks or systems) available to move money from one financial institution to another: ACH, Same Day ACH, wire, and recently, the RTP® network. Fintechs use customer account and routing numbers to move money on these rails.
Tokenizing account numbers is a solution gaining momentum across the industry; a token
is a random string of characters that are form-factor preserving credentials that use the same RT and account structure as the real account number it replaces. The Clearing House (TCH) launched Secure Token Exchange (STE) to tokenize account numbers in a way that does not alter existing payment authorizations.
Akoya is the first third-party service provider to utilize STE to tokenize account numbers on behalf of financial institutions and make these tokens available to fintechs and data aggregators.

Rising usage of digital payments

The last few years have marked a rapid growth in the digital payment markets across the world. There has been significant growth of the RTP® network, the real-time payments rail from TCH, as well as increasing Automated Clearing House (ACH) transfers, and Same Day ACH transfers, accounting for nearly 120 million RTP payments, 603 million Same Day ACH payments, and 29.1 billion ACH payments in 2021.

The growth in payment volumes connects to a massive increase in fintechs who rely on the ACH and RTP networks to offer convenient account funding, person-to-person (P2P) payments, or account-to-account (A2A) payments, remittances, and much more. However, this comes with its share of risk as fintech-enabled payments require knowing and holding a person’s account and routing numbers to initiate the transactions on behalf of the account holder.

The current U.S. data aggregation ecosystem is largely built on screen scraping and the sensitive information collected is widely shared between multiple parties. There is an increased risk of fraud if that data is exposed. In the case of a data breach, changing a consumer’s account information is complicated, costly, and cumbersome due to how widely the account numbers are used.

Tokenized payment credentials

One solution gaining momentum in the industry that can mitigate risks and reduce costs in case of a breach at a participating party in the ecosystem is utilizing tokenized account numbers. This consists of issuing a payment token to a third party (e.g., a fintech app) to stand in for the actual account number of a deposit account.

This token is often a random string of numeric or alphanumeric characters which represents nothing by itself. The token is mapped to the real account number, and the mapping is then stored in a secure vault at a trusted party.

If there is a breach of any participant, the benefits of tokenized account numbers include:

Mapping is separate and validated during payment processing, which has the ability to limit 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.

Multiple use cases and third parties would benefit from a tokenization solution:

A P2P payment app that funds a consumer’s account before enabling them to send a payment to friends. The fintech app can leverage an issued tokenized account number to create a payment from their bank account during the account funding process and for any future funding needs.

A bank that enables a new consumer to provide initial funding to their new bank account during their onboarding process. Once the account opens, the initial funds can be credited from another institution leveraging a payment initiated with a token.

A digital wallet that wants to enable A2A payments (i.e., paying directly with a bank account rather than a card) can utilize and store a tokenized account number.

A merchant that wants to store tokenized account numbers to simplify their customers’ checkout process in the future. The token can be issued with an individual’s consent and held for future use to improve the customer experience. Storing the token presents a lower risk than holding bank account information.

Any scenario that requires the storage of account information would see a significant decrease in risk (and improved security) by leveraging tokenized account numbers instead. The potential use cases are endless when you consider the way payments continue to evolve as financial technology improves.

Although it’s only nascent in the ACH and RTP payments space, using tokenized account numbers instead of real account information will soon become mainstream for demand deposit accounts. In the same way card tokenization was broadly adopted by digital wallets, we expect deposit account number tokenization will be widely adopted because it reduces the risk of storing this information.

How payments are enabled in the United States

Consumers use several payment methods today, including credit cards and checks. Yet, to fully comprehend where tokenization would sit in a bank-to-bank payment flow, it’s essential to understand how the existing U.S. payment rails move money from the payer’s bank account to a payee’s bank account.

A bank-to-bank transfer can go in two directions: A credit (a.k.a. “push”) payment and a debit (a.k.a. “pull”) payment. A credit payment is the movement of funds initiated by the payer into a payee’s account (e.g., payroll deposits from an employer). A debit payment goes the other way around and is initiated by a payee from a payer’s account (e.g., automatic utility bill payment).

As part of a payment, banks and payment network operators conduct critical processes:

The clearing process involves network operators routing messages and other information among banks, including communicating and routing payment messages to the corresponding parties and calculating their respective outstanding positions.
The interbank settlement process is the discharge of the obligations that arise during the clearing process of banks moving funds to meet any outstanding commitments.
In the context of an ACH credit payment, the payer’s bank that initiates a payment transaction is usually called the Originating Depository Financial Institution (ODFI). The ODFI has an agreement with the ACH network operator to transmit entries of payment into the network. On the other end, the payee’s bank is called the Receiving Depository Financial Institution (RDFI). The RDFI is the institution that receives entries of payment from the ACH network operator.

ACH & RTP payment flows

Let’s start with an example using ACH: Emily and Jack. Emily has a checking account with Mikomo Bank, and Jack has a checking account with Blue Pearl Bank. Both banks have an agreement with TCH as their ACH network operator.

Emily decides to transfer $100 to Jack via an ACH payment. The payment flow follows these key steps:

Emily logs into Mikomo Bank’s application and initiates a $100 payment to Jack.
Mikomo Bank creates the ACH file to debit Emily’s checking account and credit Jack’s checking account at Blue Pearl Bank. Mikomo Bank then sends the ACH file to TCH’s EPN network.
TCH receives the ACH file from Mikomo Bank and routes the message to Blue Pearl Bank as instructed by the ACH file from Mikomo Bank; this clears the transaction.
Blue Pearl Bank credits Jack’s checking account with $100 and acknowledges the receipt of the ACH file.
TCH settles the transactions between Mikomo Bank and Blue Pearl Bank.

Situations can arise in this process, leading to the ACH payment failing. These are known as ACH returns. There are more than 80 return codes. Some of the most common return codes are insufficient funds (a.k.a. NSFs), account closed, or invalid account numbers.

What would change with RTP payments? The overall payment flow remains the same, but there are some critical differences outside of the flow itself:

The clearing and settlement of funds are immediate.
Operating hours are 24 x 7, and year-round.
Only credit (push) payments are available.
All the messages sent over the RTP network are formatted according to ISO 20022.

Akoya’s role in the ACH & RTP payment flows

An ODFI needs to create an ACH file to initiate a payment. This ACH file includes sensitive information detail vital to the transaction such as the payment credentials: an account number and routing number (a.k.a. the routing transit number or RT number).

If a fintech application seeks to initiate a payment on behalf of a user, the application will have to provide its bank (the ODFI) with the user’s payment credentials. Akoya offers a secure solution for fintech apps to retrieve a user’s bank account and routing numbers through application programming interfaces (APIs) with the user’s consent in an ordinary payment flow.

Let’s return to our example with Emily. Emily has connected her checking account with Mikomo bank and the P2P payment app Paprika. Both Paprika and Mikomo bank are integrated with Akoya.

Emily has extra funds sitting in Paprika and wants to transfer some of them to her Mikomo Bank account. The payment enablement flow follows these key steps:

Emily logs into Paprika and decides to withdraw funds using an ACH transaction to her Mikomo Bank account.
Paprika uses the Akoya Payments product to request Emily’s payment credentials from Mikomo Bank.
Akoya sends a request to Mikomo Bank for Emily’s payment credentials.
Mikomo Bank sends Akoya Emily’s payment credentials.
Akoya sends Paprika Emily’s payment credentials.

After this payment enablement flow is completed, Paprika can initiate a payment through their ODFI or payment processor (this corresponds to the payment flow described earlier with the difference that Mikomo Bank becomes the RDFI and Paprika’s bank is the ODFI). This is the organization that Paprika has a commercial relationship with to initiate payments.

A fintech application will typically store payment credentials to enable future payments. Storage of credentials bears a significant risk if the data is compromised—an issue that can be solved using account number tokenization.

Tokenization within a payment flow

Account number tokenization is the process of protecting sensitive data by replacing it with a randomly generated number called a token. A token can be used to reduce the risk of fraud by allowing the use of payment credentials without sharing the actual account numbers themselves. This is done by having the token and the actual account and routing information stored in two different locations, while the mapping is stored in a secure vault.

Payment-credential tokens can be generated and issued to the ecosystem in a couple of ways:

Bank-issued tokens are created by the account-holding bank, which issues and manages the tokens so that payment originators never have the payment credentials, just the token. This is the case when a bank issues virtual account numbers directly instead of sharing the actual account numbers. This can be further broken down into three models (ODFI, RDFI, and hybrid). For ease of discussion, we will only look at an example where the RDFI issues the token, as this is the most relevant scenario when it comes to fintech initiating payments.
Network operator-issued tokens are created by a network operator entity, which issues and manages tokens as a service to bank customers that use its payment networks. This is the case with TCH's Secure Token Exchange (STE).

STE allows financial institutions to conduct a few different operations such as tokenizing account numbers, performing token status inquiries, or managing the token lifecycle. This solution is compatible with ACH and RTP networks. Consequently, provisioned tokens do not require inter-operator cooperation or industry approvals as they already act as valid alternative account numbers.

This process has no impact on how ODFIs and RDFIs manage payments as the account information is detokenized in transit by TCH during the batch processing of ACH files. The detokenization process consists of TCH swapping the token for the real account number based on the information they have stored in their secure vault while the ACH file is processed. This is possible because of a dedicated routing number used by the RDFI for the tokenized account number.

This dedicated routing number may only be used in association with tokenized account numbers and must meet certain pre-requisites. To work with STE and ACH payments, the dedicated routing number needs to be configured as an EPN endpoint. This means that any transaction initiated for this routing number will be processed on the EPN network. Additionally, because it’s configured as an EPN endpoint, any transaction that originated on FedACH will be passed through to EPN using the existing interoperability between the two ACH Operators.

The ODFI can therefore use any ACH Operator they want. The interoperability for RTP and FedNow when it comes to STE is yet to be determined.

Akoya and The Clearing House

To accelerate the adoption of STE across the financial services industry and thus reduce the overall risks, Akoya will offer a token-requestor gateway to fintechs and data aggregators. Akoya acts as an agent of the financial institution participants in the STE token service to request, distribute, and manage STE issued tokens, reducing the need for both data providers (financial institutions) and data recipients (fintechs and data aggregators) to integrate with TCH. Akoya serves as a technical connection to the service to perform certain functions on behalf of the financial institutions.

Utilizing the connection to STE, Akoya can automatically swap real account numbers for tokens and pass them to recipients on behalf of participants in the STE token service. For recipients, Akoya mitigates considerable security and risk concerns for payment enablement and has no impact on the efficiency and operation of existing payment rails.

How does the payment process work with tokenization?

To illustrate with an example: Emily has existing relationships with Paprika and Mikomo Bank, connected to Akoya. Emily has extra funds sitting in Paprika and wants to transfer money into her Mikomo Bank checking account.

(A) Payment enablement: Issuing a token to a recipient

Emily logs into Paprika and decides to withdraw funds using an ACH transaction to her Mikomo Bank account.
Paprika uses the Akoya Payments product to request Emily’s payment credentials from Mikomo Bank.
Akoya sends a request to Mikomo Bank for Emily’s payment credentials.
Mikomo Bank sends Akoya Emily’s payment credentials.
On behalf of Mikomo Bank, Akoya sends to TCH’s STE Emily’s real payment credentials for tokenization via an API.
TCH’s STE swaps the account number for a token and the routing number for Mikomo Bank’s dedicated routing number; then, TCH stores the mapping in a secure vault.
TCH’s STE sends Akoya Emily’s payments token and Mikomo Bank’s dedicated routing number.
Akoya sends Paprika Emily’s payment token and Mikomo Bank’s dedicated routing number to Paprika.

After this payment enablement flow is completed, Paprika can initiate a payment with the issued token.

(B) Payment initiation: Using the token to execute a payment

Paprika (or their payment processor) creates an ACH file to debit Emily’s Paprika account and credit Emily’s Mikomo Bank account using the token.
Paprika (or their payment processor) sends the ODFI the ACH file for payment initiation.
The ODFI sends the RDFI (Mikomo Bank) the ACH file through the ACH network. As long as Mikomo Bank uses EPN, regardless of the ODFI’s ACH Operator, the file will be routed to the EPN network endpoint.
EPN uses the STE to detokenize Emily’s payment credentials
EPN sends Mikomo Bank the ACH file containing Emily’s real payment credentials and settles the transaction.
Mikomo Bank credits Emily’s checking account after receiving the ACH payment.

This completes the entire payment flow while leveraging tokenized account numbers.

Why use Akoya for tokenization?

Through a single integration with Akoya, financial institutions, fintechs, and data aggregators can enable multiple API connections and avoid ongoing maintenance and development efforts. Akoya handles all data-sharing relationships on behalf of network participants and removes the myriad of internal and external costs required to develop and manage multiple third-party agreements. Akoya optimizes for security, transparency, and scalability, and offers a passthrough model that does not copy, store, or hold any financial data or personal information.

Akoya’s tokenization solution for financial institutions that participate in The Clearing House’s STE token service helps accelerate the de-risking of the industry:

Akoya’s solution reduces the time-to-market needed to offer account number tokenization for data providers already on Akoya’s network.
Providers can leverage the connectivity that Akoya has already built to TCH and are not required to build their own integrations to STE.
Akoya’s solution allows providers to quickly distribute tokenized account numbers to the fintech ecosystem in the U.S. through their existing relationships, increasing the speed of adoption.

What's next?

TCH’s Secure Token Exchange has been launched for the RTP network and will be targeting availability for financial institutions that utilize the TCH’s EPN (ACH) for the end of Q2 2022. Akoya is the first third-party service provider to access TCH Secure Token Exchange to tokenize account numbers on behalf of financial institutions that participate in the STE token service and are connected to Akoya’s network. Fintechs and other recipients will be able to retrieve tokenized account numbers directly through Akoya

View full post