PIMN voor beter identity management
Transactions drive the need for identity
We've been in some interesting discussions over the last few months, with organisations who need to identify their customers before they can do business with them.
Key amongst those are the Anti Money Laundering (AML) regulated organisations, such as stock/commodity/currency brokers, crypto-currency wallets in certain jurisdictions, loan providers, life insurance companies and online wagering/casino operators.
What strikes us is the commonality of approach of their online models with the approach that such organisations would have had in the bricks and mortar world (if indeed they had such).
Bricks and Mortar Transactions
Typically, in a bricks and mortar environment, the customer will approach the counter, and identify themselves first, prior to having access to the regulated service. This approach works well in bricks and mortar, as each approach to a counter by a person is generally intentioned in order to access the service and for the reason of conducting a specific transaction at the counter.
The online world is clearly different. Online customers tend to abandon transactions for the most trivial of reasons. Asking a customer to identify themselves for AML Know Your Customer (KYC) purposes up front, before they can access a full service, is a sure way to maximise abandonment. Alternatively, customers may partially or incorrectly provide identity details, which end up costing the organisation in attempts to validate. We've seen models where so called identity providers charge organisations on 'attempt' to identity a person, when the provider well knows that their process covers only half of the population. This all adds up to cost and frustration for the online provider.
We've adopted a different approach to identity, noting that it is transactions that drive the need for identity. That is, a customer decides that they want to do 'x', and will be more likely to complete 'x', if the process is streamlined, and is low friction at the commencement of the process.
Payments are linked to Identity
We associate payments with transactions, as most transactions that require identity also have a requirement for payment associated with them. Some notable exceptions are government services, however, even many of these, such as renewals of licenses, payment of fees, fines, etc have a payment component attached.
Online payments are often via credit cards, debit cards or direct debit - all of which are regulated by Anti Money Laundering (AML) legislation in virtually every jurisdiction. What this means is that each credit/debit card or bank account is a source of identity, with many jurisdictions formally recognising this to be the case. The (draft) identity frameworks of Australia recognises credit/debit card or bank account as identity sources, with the UK and EU taking a similar approach.
As identity is 'in built' to credit/debit card and bank accounts, how do we unlock the identity component and use it satisfy the requirements of AML KYC, and Government eID?
The legislative framework in Europe, Australia, the US and other countries who have adopted the Financial Action Taskforce's risk based approach, allow for a 'reasonable belief' regarding identity to be formed using payments, provided that the credit/debit card or bank account can be authenticated back to the authorised user. That is, credit/debit card or bank account are considered to be reliable sources of identity data.
Historically, credit references have also been used, however, as these are 'static' in nature, whose data may not change from year to year. The US Postal hack of todays date is a good reason why we need to move away from static databases that rely on either credit reference check and/or Social Security Number databases, or their equivalents. Static data decreases in its value each time is it used, as the probability of it being exposed to fraudsters increases with each re-use.
Our preference is to rely upon credit/debit card or bank accounts, as these in contrast are dynamic and 'live'. That is, the issuer is responsible for continuing due diligence being conducted on these accounts. The issuer is also responsible to conduct a face to face check of identity, using proof of identity documents, such as passports and drivers licenses. These are harder to forge or use fraudulently, in comparison to fraudulent use of data in static databases.
Further, the customer will also notify their bank if the credit/debit card or bank account is compromised in any way. So, any identity linked to credit/debit card or bank account is much more appropriate to rely upon than use of a static database, as they feature 'inbuilt' reporting in the event of a security breach. By monitoring the ongoing use of credit/debit card or bank accounts, we are thus able to determine that the account is still valid as a source of identity.
By using the payment associated with a transaction to assist with generating evidence of identity, the KYC process can be streamlined, creating much lower friction, and removing additional steps and manual handling of the customer on boarding and identity process. Even customers that are most likely to abandon transactions wouldn't feel that providing basic data such as their payment details and address to be onerous, or intrusive.
Privacy by Design
Whereas many customers, even persistent ones, tend to baulk at identification process that require scans or uploads of sensitive data associated with passports, licenses, and social security. These intrusive means of identifying customers lead to other risks, including exposure of ultra sensitive customer data in the event of a security breach.
We've solved this problem, and incorporated 'privacy by design' principles into our process to safeguard customers, by only collecting data that we really need to identify people. Payment data can be secured safely, and there is no need, in our view, for organisations to be collecting details regarding passports, drivers licenses, social security etc in order to achieve identification of an online customer.
As identity is created dynamically on demand in conjunction with a transaction, there is less need to build big central databases of identity, with the associated corresponding risks. We see that the entropy of dynamically created, one time identity credentials is a far superior means of protecting both the customer and the regulated organisation.
We would be pleased to assist organisations to re-engineer and streamline their identity processes, so that completing the transaction comes first, with identity proofing being as simple, fast and non-intrusive as possible, resulting in higher conversions.
Feel free to drop me a line.
Marc Bongers | Director