The eWallet On-boarding Challenge
Mar 8, 2015 1,973Views 73Likes 17CommentsShare on LinkedInShare on FacebookShare on Google PlusShare on Twitter
Let me start by saying that I think that Apple have done a magnificent job in Apple Pay. It’s a great product that has really added polish and market drive to mobile payment systems.
The focus however, is always on any negative aspect of a service like Apple Pay, especially where such a high standard is set by Apple for its products.
We’ve heard a lot these past two weeks about the problems that Apple Pay appears to be facing with regards to fraud, and in particular, the issues they appear to be having with verifying card ownership at the time of on-boarding a new customer. Its a tough process to crack, with many technical and customer experience challenges. The on-boarding challenge will also need to be solved by Samsung and Android Pay for their cart/eWallet offerings.
Before I go further, it is important to distinguish between Apple Pay and eWallets, such as PayPal and Google Wallet (in whatever incarnation it is in this week).
eWallet versus Cart
An eWallet has a means to store monies on behalf of the customer, with the ability to transfer funds person to person, or person to business, and maintain residual balances in one or more currencies.
A key distinction is that eWallets are licensed and regulated, whereas carts are unregulated.
Apple Pay is a cart, similar to those found in traditional eCommerce systems – it passes a payment transaction on to its third party payment networks, just like any myriad carts, examples of which include Magento or BigCommerce.
Apple Pay incorporates a sophisticated payment capture mechanism with some great tokenisation and security features for transmitting data. Unfortunately, those great security features don't prevent fraud if the on-boarding process is compromised. It also hasn't been designed to store money, like an eWallet does, focussing instead on localised, NFC driven, instant payments. By not storing money, Apple Pay avoids being regulated as an eWallet.
Apple choosing to be a cart appears to be by design, such that Apple avoids the myriad payment and financial regulations, and in particular the anti money laundering customer due diligence requirements, which are designed to identify who is behind any payment. By avoiding those regulations, Apple has allowed the fraud issue to manifest itself, and may have created a bigger problem for itself than complying in the first place. (Isn't that always the way?)
Anti Money Laundering Regulations
Anti money laundering (AML) regulation in the European Union and other countries requires that operators of eWallets on-board their customers by identifying them fully. This process is called “Know Your Customer” (KYC), and is no different to what a bank, credit agency or stockbroking firm requires for the opening of an account.
As Apple Pay is a cart system, it has left this task to its individual bank partners, who issued the credit card to the consumer in the first place. This is clearly causing many issues, as the banks have unfortunately adopted a fragmented approach to the issue, some of which appear to be both costly and ineffective. Some banks are using complex and expensive technical integration with home banking systems to solve the issue, whilst others are purportedly using low tech, manually driven, call centre approaches.
The challenge is to figure out a technical means to identify and determine if a customer owns the specific credit card as part of the on-boarding process. Ideally, the customer should be able to ‘self serve’, and re-use existing facilities and customer portals already provided by their issuing bank. The customer would preferably also be able to do this online, without needing to turn up at a physical counter to be identified, but with perhaps a fallback to a call centre.
Ideally, a single technical process should cater to all card types and currencies, and be able to interface at a single aggregation point, with all the card schemes payment networks.
Identifying the customer's ownership of the card is important for two reasons –
i) it gives the ecosystem confidence that a payment is likely to be genuine and honoured (ie not fraudulent), and,
ii) it serves as the basis for regulatory compliance to AML.
Card Not Present Fraud
What most cardholders don’t know or appreciate is that it is the merchant who is liable for the cost of fraud in almost every case– not the consumer, neither the issuing bank, and not the card scheme. Apple should have been aware of the prospective pain it would potentially be causing its participating merchants due to related fraud, if it gets the on-boarding process wrong. In this case, where the issuing bank and Apple are responsible for the on-boarding process, it does seem more than a little unfair if the merchants are wearing the cost of the fraud, especially if Apple is charging basis points against the value of each transaction for providing the 'service'.
If merchants start to experience and have to wear the cost of fraud at an increased rate, there will likely be a merchant backlash against Apple Pay.
Although, in a twist, it does seem from reports that Apple stores are themselves being hit by fraud, in which case Apple is the merchant, and it is wearing the cost of that fraud against the loss of its own products.
FDIC and EU Regulation
Apple’s approach has been to attempt to avoid the issue entirely, by avoiding becoming an eWallet, which in turn would require that they solve the KYC problem, and the on-boarding problem for cards.
The incoming ‘Security of Internet Payment’ regulations in the EU/SEPA require that all cards be verified before being on-boarded to an eWallet.
Whilst the US is sometimes perceived as having less stringent regulations than say the EU, the FDIC did make it clear as far back as 2012 what the requirements are for eWallets > http://www.fdic.gov/regulations/examinations/supervisory/insights/siwin12/mobile.html.
Interestingly, the FDIC refers to Apple by name in the above, and provided a comprehensive and practical guidance as to the regulatory requirements. Importantly, the US and EU requirements aren't that far apart, if starting from KYC as a basis, so a solution for one will meet the requirements of the other.
Static Data Mining
Mining of historical static data also isn't a solution, as this data may have been compromised in advance. Examples include the impact of the recent Anthem Health breach, or the US Post breach last last year. Mining of "big data" is only helpful if that data contains new information that can be used as part of knowledge based authentication.
For example, using knowledge based authentication and asking for your place of birth, date of birth, social security number (or equivalent) or other historic unalterable details, can only go so far.
We see that the dynamic creation of "small data" to be used as part of a dynamic knowledge based authentication approach is the far better solution. Particularly as in our approach and PayPal's, we create a 'secret' that can only be retrieved by the owner of the credit card account only after they pass the issuing bank's security.
This approach re-uses the familiar home banking already available to the end user, and allows the issuer to focus their security efforts on home banking systems, such as online or mobile banking, which is where the effort and customer focus should be.
Google also doesn’t appear to have solved the KYC and on-boarding challenge either, relying on static databases, and the ever decreasingly reliable Social Security Number check.
This approach also doesn't verify the ownership of the card being on-boarded, so it is still likely open to the same fraud challenges as Apple Pay. The fraud problem isn't solved entirely by KYC process, where the KYC doesn't incorporate verification of the payment instrument being on-boarded to the payment service.
All of the new mobile payment service operators, including #ApplePay, #SamsungPay and #AndroidPay, appear likely to face similar issues.
PayPal
PayPal have solved the on-boarding challenge from as early as 2002, and hold patents for ‘verifying a financial instrument’. Some 100’s of millions of people have on-boarded their cards by verifying a code or two random deposits placed by PayPal in their account.
The PayPal process works by transmitting a 'secret' via a payment message, and asking the end user to confirm the secret by accessing their home banking facilities, such as mobile, online (or even telephone) banking.
In this way, only the owner of the account can answer the 'secret'. Typically, PayPal deposits two random values into a bank account and asks the account owner to confirm the numeric values, which are randomly chosen by PayPal.
For example, random deposit values such as 13c and 8c, or 2c and 5c.
This unfortunately has the consequence that as PayPal is paying for the cost of the deposit, it will choose lower values, which reduces the number of likely combinations, and thus overall security.
This also has a further side effect whereby PayPal needs to generate transactions only for the purpose of verifying a customer's account, before they are considered as KYC'd and thus able to access full services. It is thus a "pre-boarding" step that must be passed solely for the purpose of achieving KYC, and adds delay to the overall process.
Whilst the PayPal process takes 3-5 days in most countries, it works - and it provides PayPal with a massive technical and commercial advantage, as it can remotely on-board customers at low cost with massive reach.
Interestingly, PayPal recently appealed the European Patent Office decision against it, and was granted its patent for 'verification of a financial instrument' in Europe as well, see : https://register.epo.org/application?number=EP01951030
This recent action by PayPal is significant, as some eWallet operators have been using the PayPal method in Europe, on the basis that PayPal held US and other jurisdiction patents, but not European. It also means that PayPal is serious about protecting its intellectual property, and perhaps excluding others from using their process.
The appeal timing by PayPal is also interesting, after letting the patent languish for years, particularly as PayPal moves towards being a separate entity from eBay.
iSignthis Method
The iSignthis patented service achieves a similar legal outcome to PayPal, but via different technical means, with the effect that iSignthis is real time and can be completed in 0-3 days using the credit/debit card rails.
The iSignthis process works by transmitting a 'secret' within a payment message (and thus encapsulating transport as part of secure transmission), and asking the end user to confirm the secret by accessing their home banking. In this way, only the owner of the account can answer the 'secret'.
Typically, we split a payment transaction for a 'Sales Amount' initiated by the cardholder into one or more random charges with a balancing amount, and we then ask the account owner to confirm the numeric values. This allows the cardholder to use any actual transaction (that they would do anyway) as part of on-boarding, and eliminates the 'pre-boarding' aspect, as well as the cost of the deposits (per PayPal) themselves. It also means that the number of numeric combinations possible is increased exponentially, increasing overall entropy.
This is also much faster than PayPal, as a payment of say $100 that is split into two or more charges will be processed in real time by the card processors, and accessible almost immediately by the cardholder from their home banking, whereas the PayPal deposit method takes a minimum of 2-3 days for a deposit to be concluded.
To illustrate the iSignthis process, $100 can be split as $70+$30, or $29.11 and $70.89, or $9.99 and $90.01. Of course, smaller Sales Amount sums like $1.00 can also be used.
Given that Sales Amount wont usually be in round numbers like $100 to start with, the iSignthis process starts with a number that is effectively random (the "Sales amount"), and generates at least two more (the "Splits").
As Sales Amount = Split 1+Split2+...+SplitN, the amount the end customer pays remains the same, but security entropy can be exponentially increased by iSignthis by determining not just the value of splits, but also how many splits it generates. The merchant is also settled the Sales Amount, without any delay to their payment process.
In this way, iSignthis use a transaction that the cardholder has initiated for other purposes (e.g. buy an iTunes voucher, travel, open a stock broking account, etc.), as the on-boarding initiator, avoiding the need for 'pre-boarding' entirely.
We also use a single technical interface to reach all card scheme networks on a global basis, with cross currency support in-built, whereas PayPal needs localised interfaces to initiate deposits.
The cross currency challenge is also solved, as the splits start from a common denominator (the Sales Amount), which can be used to determine the ratio of each split relative to the denominator - entirely avoiding exchange rate considerations.
There's some further neat technical features over what PayPal can do, but you need to talk to us about those.
The process can be used to onboard customers remotely to any AML Regulated service, including banking, credit, stockbroking, cryptocurrency exchange etc - which means that that initial payment for whatever (regulated) service can also act as the basis for KYC.
Harmonised, Single Point Approach
With Apple Pay, each bank is adopting it's own on-boarding approach, which in turn is leading to fragmentation in security, and what appears to be a rise in fraud. Perhaps Apple (and other eWallet providers) could consider a harmonised technical and customer experience approach across all of the issuing banks, that would allow them to manage and control customer on-boarding? This would also have the benefit of a consistent customer experience, particularly where a customers seeks to on-board cards from different issuing banks.
Ideally, the on-boarding approach would work in real time for all issuers and card schemes, without the need for complex and individual bank technical integrations, whilst being intuitive to use for customers to self verify ownership of their cards
That sounds a lot like what we at iSignthis do.......perhaps we can help. (hint to any Cart and eWallet operators, watch the YouTube Video below, up to the 3.15" mark)
ISX Price at posting:
17.0¢ Sentiment: Buy Disclosure: Held
