Crossing the rubicon: The point of value transfer
0 comment(s)
Any conversation about real-time fraud detection is incomplete, maybe even pointless, without including the concept of value transfer. It's a pretty straight forward concept, but it seems to be overlooked in much of the rhetoric that is out there on this topic. Put simply, value transfer is when the value of a transaction moves from one party to the other. The reversal of that transaction would require some sort of recovery process. Value transfer is a two way exchange where each party receives something of value to them, but may not happen simultaneously in both directions. I want to take a closer look at the value transfer involved in the payment side of the transaction. For now we will look at check, ACH, and debit card.
- Check – from the paying bank's point of view, value transfer occurs on a check transaction at midnight the day following presentment (possibly earlier depending on the item), the return deadline. It can certainly be returned after that, but it would have to be as a collection item and therefore open to negotiation and potentially litigation.
- ACH – The return deadline for ACH items is the same as that for checks for most items. The notable exception is for unauthorized transactions on retail accounts. NACHA regulations stipulate 60 days from the settlement date of the transaction for this type of return. Reg. E goes farther than that giving 60 days from the statement date when the item is reported.
- Debit Card – All EFT (Electronic Funds Transfer) transactions fall under Reg. E, in this case giving the retail cardholder 60 days from the statement date where the transaction appears to refute the transaction. That can be up to 90 days after the fact, but there are other value transfer events that take place between the parties as the process plays out.
There's a lot of talk about real-time detection, but what does it really mean? As with many complex issues, the real answer is "it depends". Real-time only has significance in relation to the ability to interdict transactions before value transfer takes place.
One general use of the term real-time has to do with the ability to process input immediately as received and produce output as soon as processing is complete. Even a batch process based system can meet that definition when batches are discretely processed when presented rather than aggregated.
Debit Card transactions are particularly troublesome because of the complex rules surrounding chargebacks and the shifting liability depending on the circumstances of the transaction. That's why so much effort is expended (checking account balance, card and account status, velocity and dollar limits, placing a hold, etc.) to be sure a transaction is good at the time of the transaction. Note that this effort is done for the joint benefit of the merchant acquiring bank and the issuing bank since both have risk in a chargeback situation and both want to avoid that situation if at all possible.
If the card issuer going to detect fraud on these transactions, it is best to do it in the context of the approval window, allowing for interdiction. In the cased of the debit card POS purchase, millisecond response is needed because in most cases for card present transactions the liability moves from the merchant acquiring bank to the issuing bank at approval. In effect value transfer for the payment has occurred. While the balance and other items noted parenthetically above are checked and a hold is placed on the account traditional approval checking does not evaluate the potential for fraud. Any fraud review must take place within the existing transaction flow timing wise.
ACH has a more relaxed timeline in regard to releasing transactions. We all know that recalling credit transactions is at best difficult because the RDFI has no obligation to return it if there are insufficient funds in the receiver's account. For debit transactions, since the ODFI bears such an extended risk of returns, the value transfer that drives it is the value transfer to the originator. So for ACH, you want to make sure you do fraud detection before you release the file. For example, if you want to make the 5:00 ACH operator deadline and you have given your originators a 3:30 deadline; you have 1½ hours to interdict fraudulent transactions.
Check fraud, specifically on-us fraud, is driven by the return deadline on the item, the longest being midnight the day after presentment, but local clearing house deadlines may be earlier. Still, if I am able to input items from my transaction processing system rather than after posting, I have several hours to interdict those fraudulent items. On the deposit fraud side of the coin detection timing has to do with value transfer to the depositor. You must detect and hold a fraudulent deposit before the depositor has access to those funds. That time ranges quite a bit from situation to situation.
My conclusion is that real-time does not mean immediate. It means just-in-time (in regard to taking action), and that varies from situation to situation.