I wrote an initial post about the poor implementation of OTP by Interswitch (ISW) — you may want to read that post first. This post looks to demystify some of the assumptions around online card fraud and associated risks as this is the main justification for implementation OTP in such a crude manner in Nigeria.
I smiled when I saw this from a user…
“I just got back from an ATM where I have made an attempt to register for safetoken. I have got all the way to paying the due 1 naira.
But now I am trying to make a payment via quickteller.com and I am not getting the expected prompt to add OTP.
Is it supposed to be this hard?”
The comment really sums it up. These guys have bungled the process of authenticating a cardholder and have simply focused so much on the technical issues rather than processes and objectives being sought after. No doubt the banks have some part to play in making this process more streamlined.
With or without Mr. OTP, the issue is really about risk.
OTP as a second layer authentication broadly serves two purposes
1. Helps validate (to some degree) the cardholder initiated the said transaction
2. Increases the probability of a liability shift to the issuing bank should a chargeback occur
To appreciate these points, it is worth exploring the lifecycle of a typical card transaction.
In an ideal scenario, you would expect the cardholder pays via merchant site, acquirer processes via card associations (VISA et al), issuing bank settles and merchant gets paid and everyone gets a slice of the deal. Voilà!
Unfortunately this is not always the case. Often, a cardholder may contact their bank (issuer) to dispute a transaction because of fraud, non delivery etc. The card issuer on behalf of the cardholder puts forward a dispute to the acquiring bank to challenge the said transaction(s) which could result in a chargeback (reversal of the original transaction).
As most chargebacks relate to fraud/unauthorised transactions, what ISW’s OTP does is provides a stronger case for the acquiring bank/ISW by bolstering their position and reducing the chances of a chargeback/reversal.
I am of the school of thought that there are many ways to skin a cat – there are many ways (or a combination of ways) to achieve a similar objective and I explore a number of these.
A merchant account is akin to line of credit.
It is worth noting that a merchant account is in fact like a line credit as it exposes the acquiring bank/provider to credit risk (the risk that the merchant will be unable to repay debts due or make required scheduled payments) due to chargebacks etc.
Such exposures need to be managed efficiently no doubt and banks worldwide rely on complex risk engines in addition to manual intervention to process transactions. It remains a delicate balance of ensuring that the merchant provider’s risk appetite is satisfied (profits etc.) versus the user experience, costs etc. If ISW are looking to take a zero tolerance approach towards risk by closing the door, they might as well be willing to bow to new players who will take their place.
When a merchant account is viewed from the perspective of a line of credit, it becomes ever more evident that merchants have a huge role to play around fraud management. However to achieve any traction, merchants need to be equipped with the tools to manage/control transactions they receive.
It is never a silver bullet but a holistic approach towards risk.
It is really about a combination of methodologies towards accepting and managing risk and never a one shoe fits all approach.
I explore a number (or combinations of) of strategies as alternatives…
1. All Nigerian MasterCard/Visa cards should automatically be enrolled under 3D Secure by the respective issuing bank(s). Activation of 3D secure by the cardholder should be a simple intuitive process based on KYC data available to issuing banks. Enrolment not only protects local merchants but also international merchants wanting to accept Nigerian cards. By doing this, if a merchant in the USA looks to accept Nigerian Visa cards, s/he can simply switch 3D Secure rules on and get the same protection irrespective of location.
2. Implementing 3D Secure should be a choice left to each merchant/store and there should never be a blanket approach. After all, the merchant benefits from implementing a scheme such 3D Secure as it provides evidence in transaction not authorised disputes. If ISW really want better adoption of 3D secure, then incentivising merchants by providing lower fees on transactions that pass 3D secure is one way or transferring such benefits or costs (for non adoption).
3. Merchants need tools to review and reject payments depending on their risk threshold. If you are going to put me on the hook for something, I really need to have some level of control. Basics such as controlling the state of a transaction (e.g. authenticating vs authorisation), rejecting payments and refunds are a must.
4. Implement a variable Merchant Discount Rate (MDR) to take into account the risk profile of a merchant – ISW currently charge a flat rate of 1.5%. The MDR is the rate charged by a provider to process cards transactions and covers fees paid to 3rd parties (issuer, Visa, MasterCard, agents etc.). The MDR must take into account fraud/credit risk. It’s only common sense that riskier merchants (no trading history etc.) should pay a higher fee to process card payments.
Store merchants in Nigeria must wake up to the fact that they would have to pay a premium in the interim to accept card not present transactions.
5. Implement cash reserves based on the merchants risk profile. This could be anything from 1% of sales held for a specific period (to cover exposure). This reserve serves as a buffer for future chargebacks that may occur. Again this will depend on the risk profile of the merchant.
6. Increase the settlement period to take into account the risk profile of the merchant. For example a new merchant with no trading history could be placed on 14 day settlement period which creates a buffer.
This list is by no means an exhaustive one.
PS.
What is ISW’s chargeback policy?
If implemented well OTP could work – remains an if.
This post first appeared on Peter’s blog.
