Account Information Services as KYC enablers

How can Account Information services enable smoother Non-face-to-face KYC processes?

 

A few weeks ago in this write-up I proposed some ideas on how AML Law can evolve to enable financial service providers to innovate their customer on-boarding experiences. One of my suggestions was that the AML Law of the future should abandon exhaustive lists of mandatory KYC measures that circle around specific technologies and instead lay out the minimum elements for an adequate AML risk assessment while allowing financial service providers to devise and implement KYC routines that effectively address any identified risks.

That piece was a very long chunk of text by internet standards, so this time I will try to keep it succinct and focus on a very interesting set of regulated services contemplated in PSD2 that are particularly well-suited for building seamless KYC routines in the context of online/Non-face-to-face financial services. I am referring specifically about Account Information Services (AIS), defined in Art. 4 (16) of the PSD2 as follows:

"An online service to provide consolidated information on one or more payment accounts held by the payment service user with either another payment service provider or with more than one payment service provider;" 

What I propose is that AIS can be used by financial service providers to build the kind of enhanced due-diligence measures that are required by AML Law whenever an AML risk assessment shows high risk indicators such as business relations or transactions that take place fully online (or non-face-to-face). A hypothetical enhanced-due diligence measure that relies on AIS in the context of online consumer credit, for example, could be outlined as follows:

1. Credit applicant is prompted to fill in an online credit application form that is deliberately designed to gather information that could be later on verified by means of AIS. This information could well be: IBAN numbers, exact names of account owners, name of banking institutions, etc.
2. Once the Credit applicant has filled-in the online credit application form, the Consumer Credit Provider obtains his/her consent to work with a licensed Account Information Service Provider (AISP) in order to gather information from the applicant's account(s) disclosed in the form.
3. Once the AISP gathers the account information and passes it on to the Consumer Credit Provider, the latter cross-checks the information gathered directly from the account and the information that was provided by the customer in the online application form. This can be done automatically, without the need of human interaction. If there is a good match between the information provided by the customer and the information collected by means of AIS, then the enhanced due-diligence measure can be deemed to be fulfilled.

Here is a flow-chart of how that routine could look like:

Now, the kind of routine I described above is not a silver bullet for all types of transactions and should probably be accompanied by some sort of complementary ID verification, but if we look at the history of enhanced due-diligence measures that were accepted as valid for NF2F transactions in the AML Law of most jurisdictions, it becomes apparent that this routine is in some ways a superior analog to the once ubiquitous "Cent-Transfer" or "Penny-testing" routine which, in the European context was widely accepted as mimicking one of the examples in Art. 13. 2 (c) of the third AML directive:

"(...) ensuring that the first payment of the operations is carried out through an account opened in the customer's name with a credit institution."

This so-called "cent-transfer routine "typically consisted on prompting a prospective customer of financial services to make a very small payment to the account of a financial services provider in order to ensure that the first payment (and the subsequent transactions that took place in the course of the relationship) were done, whenever necessary, through an account opened in the customer's name with a bank that, in turn, had an obligation to carry out KYC routines on the prospective customer and probably had done so before opening the account from which the first payment is initiated.

In my mind, it is easy to see that the routine I briefly described above as the AIS KYC routine is ultimately not so different from the "cent-transfer" routine. In fact, assuming that the AISP collected the account information in compliance with the Secure Customer Authentication standard enshrined in the regulatory framework of PSD2, it is clear that the AIS routine would allow a financial services provider to corroborate with a good level of certainty the ownership of the payment accounts of its prospective customers and to safely initiate a business relation insofar as the verified payment account serves as the basis for the new "non-face-to-face" relation with the customer in question. (In the case of credit, for example, the consumer credit provider can simply refuse to disburse any loans to accounts that are not adequately verified by means of AIS).

Again: This is no silver bullet. In non-face-to-face contexts there is always the risk of impersonation but this routine seems solid enough especially if accompanied by a proper AML risk assessment and by an adequate system and methodology for transaction monitoring. I should say that my team has not yet been successful in getting the approval for this kind of routine as a compliant NF2F KYC routine by the Spanish AML Authority (after two years of well written submissions with detailed explanations on the processes and technologies involved) but I tend to think that now that the PSD2 is here, companies like Kontomatik, Figo and Perfios that have built significant expertise and reliable APIs for the provision of account information have one more interesting application for their technology: In the the very near future they might just be perceived as key enablers of seamless and compliance-enabling NF2F KYC routines.

Tweet

Automated Decision-making, Evil Algorithms and other Latent Dystopias

A brief epilogue to my participation in CPDP 2017

It is getting very personal indeed.

Companies in all industries are actively looking into the possibility of harnessing personal data for making better decisions in many realms:

• How to better invest their capital and use their resources? 
• How to customize certain products to satisfy individual customer needs? 
• Is a given individual eligible for insurance coverage? If so, at what price? 
• Is a given individual eligible for consumer credit? if so, what kind of credit product?

This renewed interest for personal data as a decision enabler coincides  (or perhaps it is explained) by the fact that we live in a time where technology allows for tremendous amounts of personal data to be generated, collected and processed at a mind-numbing scale and speed. 

So, if we take a look at this future that we live in,  there is no escape to the realization that all of this can go really bad.  There seems to be this latent and very possible dystopia waiting to occur that is eloquently portrayed in some of the posters of the CPDP 2017 conference:

It is not such a stretch of the imagination to think of a world where machines located in remote and undisclosed places get to make obscure yet critical decisions that affect our lives in all kinds of ways.    A machine that decides that someone will not be covered by insurance, a machine that  decides that someone is inapt for a given job, a machine that decides whether you are liable to pay a big fine.  All without a clear explanation…  all without a reason that seems fair or at least mildly intelligible.

It is important that we all realize that this kind of dystopian future is very possible.  Preventing it from happening is perhaps one of the main challenges to be addressed not just in the realm of fintech but in many other spaces.  All of us as citizens, legal practitioners, regulators, entrepreneurs and activists have a lot of work to do to prevent it from becoming a reality and Data Protection Law offers a very handy toolkit for doing just that.  All kinds of legal operators (judges, regulators, legal practitioners)  should keep this latent dystopia in their minds when they go about the very sensitive work of  giving meaning to the 200 pages of the GDPR, for example.

But no matter how urgent and critical  that challenge is, we should also admit that it is not the only one.   At Kreditech, for example,  I have seen many ways in which the right use of automated decision making can have a very positive impact on people’s lives.

We have the good fortune to employ people from the consumer credit 1.0 world who are working closely together with the data-scientists who build all these spooky algorithms.  Whenever these two get together, the former very readily admit that no credit policy, credit officer or respectable credit analyst would have ever considered issuing loans to some of the people that "our algorithms" issue loans to.   

Initially, this sounds very concerning: Why would we ever issue loans to this people?
The fact is, however, that our data-scientists have consistently observed in the data that a big chunk of this very same people that would have been denied access to credit by 1.0 Lenders are actually very good at repaying their loans in time.  We could even hypothesize that there must have been some kind of bias in the way creditworthiness was assessed by humans (and in the old methods) that prevented some people (perhaps due to superficial perceptions related to their socioeconomic status)  to gain access to consumer credit.

This is rather revolutionary:  We might have in our hands the kind of technology that has the potential to help us advance a very important agenda: the agenda of inclusion. In the case of Kreditech: The agenda of financial inclusion.  But this could be happening in insurance as well in the sort of mysterious and unpredictable way that innovation tends to happen.  What if machines are able to see something in the data that opens the possibility of affordable insurance coverage for individuals/SMEs that have been historically deemed to be too risky to be insured?

The realization of these possibilities should bring us to our second challenge:  That whenever we are engaged in the laborious task of construing and giving meaning to Data Protection Law, we make sure that we strike the right balance between building regulatory frameworks that impede the dystopia that was prophesized ad-nausea in CPDP 2017 and the need to enable innovation,  the kind of innovation that lifts us and keeps us moving forward.

It is very important that we go about that discussion with open minds and open hearts:  How do we get this balance very right?   Innovation is desirable and important and can be harnessed for the good of mankind.  Frank Pasquale and Nicholas Diakopolous, for example, seem to propose an interesting first approach to this in the form of Algorithmic Governance and accountability.  That might just be the way to move forward: Understanding that algorithms are not necessarily evil but need proper governance and accountability models.  That seems like a very interesting discussion.

But there is also a very unproductive and terrible way to go about this issue:  The way of demonizing businesses and insisting that DPAs build a corpus of Law that stifles and regulates innovation away.   A world-view that sees regulation as conduit of our worst fears and our worst fears only, leaving no room for the best of our aspirations.   

 CPDP 2017 was a great event but it was very disappointing indeed to hear very senior and influential policy-makers demonizing certain business models without any sophisticated or nuanced arguments, on the basis of, for example, inacurate media coverage about the number of data-points used for decision-making.  It was also very sad to see that none of the tech giants that attended the conference insisted on the need to preserve innovation and harness it for the good but seemed busier with looking cool and concerned and in the eyes of the Privacy Community.

One can only wish that whenever we all go hunting for latent dystopias, we don’t end-up shooting at some of the practices and technologies that could bring us closer to certain outcomes which, analyzed more carefully,  look more like the stuff of utopia.

Disclaimer: The opinions expressed by the author in this post are strictly personal and do not reflect the official position of the Kreditech Group.

Tweet

Agile, Fintech & Product Management in Regulated Spaces

Of all the twelve principles in the Agile Manifesto, number four is the one that draws my attention the most:

Business people and developers must work 
together daily throughout the project.

And it is particularly interesting because it seems to be a vivid reflection of the recognition that a good degree of cross-functionality is essential to  ensure that commercial requirements (typically the priority of "Business People") are adequately addressed in the final product.  By adhering to this principle an Agile enterprise avoids fostering the outdated and pernicious distinction between "the business side" and the "technical side" and instead emphasizes a cross-functional collaboration aimed at delivering tangible business value.

It is in that spirit of cross-functionality embraced by the Agile methodology that I propose to expand and build upon in this piece. In fact, one of the key things I have learned in my role as the Legal and Compliance guy  at Kreditech is how important it is for "Legal and Compliance People" to work very closely with  "Business People", “Product People” and Developers.

In the Kreditech Group we operate across several geographies and run an integrated financial services platform comprised by three different credit products.  These products are complex not just from a commercial perspective but also from a regulatory perspective. In fact, most countries have adopted legislation that determines the way in which credit products are to be structured, marketed and priced to the point that firms engaged in credit issuance face a level of regulatory-driven complexity that is not typical of other domains. This is particularly true for the Kreditech Group which develops software in order to deliver on its commitment to build the most convenient and user-friendly online borrowing experiences while remaining compliant with both applicable Law and regulation (including self-regulation).

It is in a space as regulated as credit where it becomes clearly apparent that CEOs and Strategists need to understand the many ways in which Law and Regulation constrain their formulation of corporate strategy, but also where principle four of the Agile Manifesto seems to gain another dimension: The creative impulse of product teams is also constrained by Law, so it is not just a symbiotic relationship between "Business People" and Developers that is required but also a symbiotic relationship that includes "Legal and Compliance People".

Perhaps what is necessary is also that "Legal and Compliance" people start seeing themselves as "Business People" in the sense that even when they assume the typical role of "Compliance officers" they operate under the premise that their main role is to assist the organization to remain compliant instead of simply controlling and monitoring. That is, however, a more complicated discussion, so at this point I would steer away from it in order to propose some non-exhaustive measures and attitudes to embrace in order to foster the kind of healthy collaboration that is required between "Product People" and "Legal & Compliance People" in heavily regulated spaces:

1. Earlier is always better. In fact, no matter the flexibility and adaptability that is emphasized by Agile, it is very important to involve Legal & Compliance personnel very early on to ensure that at the very moment the product is conceived they are able to flag its inherent risks and legal nuances so that these are reflected in product requirements and specifications. This, in my experience, is very critical to avoid that Legal & Compliance personnel adopts a reactive stance towards the development process but instead acts as a partner of the Scrum Team since the very beginning.
2. Interdisciplinary Professionals are key.  The in-house Legal team of a fin-tech company should strive to recruit individuals who are tech-savvy enough to be able to speak the language of developers in order to assist Product Owners in the process of translating legal provisions, regulatory guidelines and court decisions into product specifications.  While Prof. Lawrence Lessig has argued that Code is Law, in this context it would also be valid to argue that one of the roles of the In-house Legal team is to assist the process by which Law becomes Code. Conversely, product people who have experience in regulated spaces and/or a good nose for regulatory issues are always an asset.
3. Precise documentation is of the essence. The legal questions posed by the product vision of a fintech product owner are typically not plain-vanilla. A question on a specific point of credit law, for example, could have a different answer depending on whether it is made in the context of revolving credit or installment loans or bullet-repayment loans.  Therefore, it is very important to be able to document the product vision very thoroughly and holistically in order to allow structured legal analyses.  Good product documentation becomes particularly critical when it becomes necessary to engage external expertise in order to find an appropriate answer to a complex question at hand.  In the absence of adequate documentation, an attempt to make an in-house legal assessment of the product vision (or out-source it)  becomes very expensive guess-work:  What does this or that product owner really have in mind?
4. Make Legal & Compliance Personnel an integral part of Scrum: The ideal scenario here (if not making them part of the team) would be at least to have them present in the process of revising increments and planning next steps after every sprint.
5. Is it possible to think of the Legal nuances of the product as Features? This is perhaps a bold suggestion and I am sure it will be anathema to some Product Managers, but in an ideal world legal/compliance requirements are seen as product features and there is a scrum feature team who is dedicated to deliver them.   Why not?

In my experience none of the attitudes and measures mentioned above are easy to embrace or implement. Having this constant interaction between Product Teams and Legal/Compliance teams is very frequently not a friction-less effort.  It takes a lot of patience and commitment from both sides.

However, I will venture a prediction: Some of the next great innovations in fin-tech will stem from this constant dialectic between interdisciplinary professionals: Between great product people and great legal & compliance people working together to build amazing customer experiences and deliver business value in a regulated world.



Disclaimer: The opinions expressed by the author in this article are strictly personal and do not reflect the official position of the Kreditech Group.

Tweet