As open loop prepaid cards become more common among unbanked and underbanked consumer groups, Issuing banks and Program Managers have a unique opportunity to capture and/or increase deposit and fee income by promoting and educating cardholders on the benefits of receiving pay electronically. In fact, the only way for consumers to fully experience the benefits of a prepaid card is to "electronify" their income from the disbursement point. By doing so, consumers will eliminate the high cost associated with handling cash such as check cashing fees, money order fees, and not to mention loss due to theft.
So how does money get from point A to point B?
In a traditional Direct Deposit setting, an employer instructs the bank and/or service provider to originate a transaction on the business Demand Deposit Account (DDA) to credit an employee checking account via the Automated Clearing House.
The transaction flow looks like this:
Employer DDA / ODFI >> Federal Reserve/ACH Network >> RDFI / Employee DDA
In Prepaid, the transaction differs because a true DDA on the receiving end doesn't exist. A custom process is created to allow for transaction data and funds movement to flow between two separate ledger systems.
Understanding issuing bank and prepaid account structure
From the issuing bank perspective, there is usually a single account designated to hold all funds represented by individual prepaid account balances on an issuing processor's system. Some banks choose to use a two account system to capture value loads with a subsequent funds movement into a settlement account based on cardholder usage but the concept is still the same - Issuing bank holds the money, Issuing processor holds the accounting. Another key point is that value on the issuing processor's system does not mean funds are in the bank.
To facilitate a Direct Deposit, the issuing bank must identify all transactions associated with prepaid accounts as they come in from the ACH Network. Remember, prepaid accounts do not exist on the banks core DDA system so the identification process is a critical step in the process. To accomplish this, a reference number (some refer to as a Pseudo DDA) is associated with each 16-digit PAN at the time of account creation specifically to support funding via ACH. The reference number is the equivalent of a checking account number. In the past, some processors simply used the PAN as the reference number but this methodology is no longer used for security reasons. Imagine millions of card numbers floating around the ACH Network!
Getting funds and data where they need to go
With the reference number or Pseudo DDA system in place, the receiving bank will use a custom process or application to identify ACH deposits associated with prepaid accounts. The primary objective at this point is to tell the receiving bank's core system to not reject the incoming deposits. The second objective is to make a decision on what to do with the transaction.
Here is a typical scenario:
- Core banking system receives NACHA files from FED containing reference numbers
- Core banking system parses out reference numbers and calculates all prepaid related amounts
- A single entry is made to a bank designated account with bulk funds until cardholder consumption.
- A file is prepared with all payment reference numbers and individual credit amounts, and is delivered to the issuing processor for application of value to each prepaid account.
This process adds a few more steps between the employer and employee but is an interesting representation of how prepaid systems interact with traditional banking infrastructure.
