domingo, julio 09, 2017

Undemonizing Screen-Scraping (Or why Screen-Scraping matters)

Flickr Website  Extreme macro picture of the white background of a website. By Paskal under a creative commons license.



One of the most controversial questions about the implementation of PSD2 seems to be the question of Screen-Scraping. In fact, the European Banking Authority, the institution tasked by the PSD2 to build the Regulatory Technical Standards that make "Open Banking" possible, proposed the following working definition of screen-scraping: 

"a way for the PISP to access the customer’s online account by pretending to be that customer, often using advanced robot technology." 

Wow. What a telling assertion. It is phenomenal because it shows the inherent bias in the discussion about the viability of Screen-Scraping under PSD2. Some rabble-rousers might even suggest that this working definition proposed by the EBA confirms that the latter has paid too much attention to the market incumbents who have a vested interest in advancing a certain demonized notion of Screen-Scraping and very little attention to the innovators whose business models and interests are aligned with the openness ideals enshrined in the PSD2 . It is the European Banking Authority after all, some have said. 

So let's indulge the rabble-rousers and take a closer look at the definition proposed by the EBA and the issues that it brings about:

Firstly, it presents Screen-scraping as a technology that is only used by PISPs, seemingly oblivious to the fact that this technology is also particularly important to companies that engage in the business of Account Aggregation. As a matter of fact, the companies that the PSD2 has now come to baptize as AISPs have been using this kind of technology for their business for a long time, mainly because screen-scraping is not much more than the process of "collecting screen display data from one application and translating it so that another application can display it" (Techopedia). 

It is important to note that in the absence of the Bank APIs that have been heralded after PSD2, there were very little options for the companies who operated as Aggregators of Account Information but to collect human-readable screen display data, parse it and convert into the format that was most useful to their clients. I am no expert in the technology, but even Wikipedia suggests that the technique can be as simple as "capturing the bitmap data from the screen and running it through an OCR engine", which sounds simple enough even for the uninitiated and has nothing to do with PISPs because the notion of PISP is an artificial construct created in the policy discourse of the PSD2. In fact, I guess it is plausible to think of the notion of Payment Initiation Services as a name given to a particular activity carried out by certain companies like Sofort or perhaps as a certain legal term to address a defining aspect of the business model of the Soforts of this world: The initiation of Payments from a given end-user account held at a financial institution who is a third-party to the institution initiating the Payment. 

The underlying problem is therefore that the EBA definition fails to account for the full complexity of the phenomenon it intends to regulate and betrays the principle of "Business-Model Neutrality" that is mandated by Article 98. 2 (d) of the PSD2. In fact, it assumes that Screen-Scraping is constrained to a business model and (hopefully inadvertently) fails to see the importance of the technology for Account Aggregators that soon will become AISPs. 

In my view, the narrow regulatory vision that this definition betrays should be enough grounds for the European Commission to reject the RTS as it stands, but I would argue that there are more and perhaps even more alarming reasons to do so and that the definition of Screen-Scraping proposed by the EBA makes them very apparent. 

In fact, The Second issue with the definition is not only that it is flat-out wrong but also that it is suspiciously wrong. And I say that it is suspiciously wrong because the actual technique of Screen-Scraping is very different to what the EBA has proposed in its definition and because this mismatch between the actual characteristics of the technology and the definition of the EBA is so patently obvious. It took me two clicks to get to this description of Screen-Scraping in the Techopedia and two clicks to get to this other one in the Wikipedia. Screen-Scraping is not really the most obscure of concepts, it doesn't take a panel of experts to get a basic grasp of it.

However, after a public consultation process that was full of expert commentary, the EBA has embraced the wrong definition and not just a randomly wrong definition but a definition that very closely resembles the demonized picture that certain pundits and market incumbents have painted of Screen Scraping. In particular, please note that the definition proposed by the EBA concocts a technique to capture and present data (screen-scraping) with the act of impersonating an account-holder or, to quote directly from the RTS, with the act of a PISP accessing a customer's online account "pretending to be that customer". 

What a diabolically perfect definition that is. What a PR triumph. In reality, it is nothing but the preferred vision of the obdurate interests that managed to get a hold of public discourse and mislead public policy. No policy-maker in full exercise of its capacities would vouch for an account access method that is based on impersonating account holders. 

It is not a secret that banks have been advancing this view of Screen-Scraping since they first saw it as threat and that they have done an extremely good job at cementing it in the public discourse as the pervasive portrait of Screen-Scraping. I have been so painfully aware of this effort for the past two years that whenever anyone in the Account Aggregation space asked me about how to deal with the Screen-Scraping question I tended to suggest: Please emphasize that you are an account aggregator and that screen-scraping is simply one way in which you can do the job that your clients have entrusted you to do. 

Again, that is what Screen-Scraping really is: One of the many ways in which account-aggregation can be done. It is not (as the EBA suggests in its definition) an account access method that presupposes the impersonation of account-holders, so it is not far-fetched to say that the EBA has made an unacceptable exception to the principle of technological neutrality by deciding to reject this specific technology under a mischaracterization, that is, by attributing a specific abhorrent false characteristic to it. 

In the interest of intellectual honesty, it is important to say that many Account Aggregators-soon-to-be-AISPS have typically engaged in a practice that is very easy to mischaracterize as "impersonation". And this is where the PR battle was won by the banks since the very beginning. In fact, what many Account Aggregators and PISPs do is that they set-up authentication interfaces that prompt account-holders for their personalized online banking credentials. These interfaces typically take the form of widgets into which the account-holder is effectively requested to type her online banking credentials. 

Here is a good example from Sofort: 




What happens after the account-holder has provided his authentication credentials is that a machine operated by the Account Aggregator or PISP logs-in to the online banking infrastructure of the Account-Holder's bank (or e-money institution) on behalf of the Account-Holder and carries out certain actions that are expressly mandated (and consented) by the Account-Holder. This is effectively how Sofort manages to initiate payments from accounts held at all major banks: by initiating the same process that goes on with an account-holder receiving a TAN on her cellphone and typing it into a web-interface. For account aggregators, the risk profile of this particular process is greatly diminished by the fact that they do not initiate transactions but simply skim (scrape) the data presented for human-reading in the online banking interface and convert it into the format instructed by the Account-Holder. (There is typically no need for the account-holder to type its TAN into the Account Aggregator's web-interface). 

The issue that the bank PR savants seem to have exploited is that this exchange of credentials occurs by means of user interfaces located outside of the infrastructure and control of the banks, so they have insisted in portraying the process I described above as one in which a very dubious company induces very valuable bank customers to disclose their sacred credentials and then uses those credentials to impersonate said customers with the goal of initiating all kinds of risky transactions in their accounts. 

Smart. Incredibly smart PR. But the PSD2 mandated the EBA to look beyond the PR discourse and bring about a set of regulatory technical standards that uphold all of the directive's beautiful ideals of openness while remaining both technologically and business-model neutral. Most importantly, the PSD2 has mandated the EBA to uphold a very important new right in the acquis, very eloquently phrased in Art. 67.1 of the directive: 

Member States shall ensure that a payment service user has the right to make use of services enabling access to payment account information as referred to in point (8) of Annex I. 

Under such a grandiose mandate, the least a European Citizen can expect from the EBA is a thorough understanding of the phenomena and technologies that it intends to regulate. The least a European citizen can expect from the EBA is that it sees through the PR discourse and realizes that its working definition of Screen-Scraping concocts two distinctly separate technological phenomena: A technique used to collect and present data (screen-scraping) and an issue of secure authentication. An EBA that was free from the pressure of the obdurate PR cloud would have easily seen this difference and would have not flat-out prohibited a technique for collecting and presenting data by assimilating it to a certain authentication problematique that is, by the way, arguably solved by having the banks build their own authentication APIs. This might be the interface the PSD2 actually needs for its succesful implementation: A bank-side authentication API that allows account-holders to safely grant access to AISPs and PISPs to their accounts without putting their credentials at unnecessary risk. 

But why go to such lengths? Why is it so important to preserve Screen-Scraping at least (as the European Commision has suggested) as a fall-back option? Well, I don't want to advance any conspiracy theories, but it is no coincidence that the ones whose interests are anchored in the past (Please read: the banks) have gone to such extreme measures to demonize Screen-Scraping. 

The reason they have done so is that Screen-Scraping is really the one technology that puts the account-holders in a position to exercise almost unrestricted ownership of their banking data. In fact, this technology effectively challenges like no other the unquestioned monopoly that the banks have over the data of its account-holders and most drastically opens the door for innovation and disruption. 

If the banks get their way, they would prefer to be the ones building APIs that determine what data is available, how is it available and most importantly, when and how fast is it available. They would prefer not to open the door for disruption, which is a stance that entails closing the door to screen-scraping. In a world where immediacy and convenience and ease-of-use are such important customer propositions, a poorly implemented or faulty bank API could result in tremendous business disruptions for AISPs and PISPs. Can you imagine what would happen to Sofort if it regularly starts asking its end-users to wait a few minutes until the Bank API responds prior to initiating a payment? 

Well, the fact of the matter is that the banks have very little incentives to build the APIs that AISPs and PISPs need for providing great customer experiences. On the contrary, they have incentives to discourage their users from abandoning their technological ecosystem in favor of the payment services of third parties. So: Why did the EBA decide to leave AISPs and PISPs at the mercy of the banks? Isn't its mandate to actually foster innovation? 

EBA's response to this line of questioning would induce a small seizure of joy into any libertarian thinker looking for easy vindication. Their response is a "four-fold alternative approach" that promises supervision and supervision and more supervision: 

  • "a requirement for ASPSPs (please read this as banks) to define transparent key performance indicators and abide by at least the same service level targets as for the customer interface, regarding both the availability and the performance of the interface, as well as qualitative measures to assess whether or not they are doing so (Article 31(2));
  • a requirement for PSPs to monitor and publish their availability and performance data on a quarterly basis (Article 31(3));
  •  a requirement for ASPSPs to make the interfaces available for testing at least three months before the application date of the RTS (Articles 29(3) and 29(5)); and a review of the functioning of the interfaces as part of the review planned for 18 months after the application of the RTS under Article 36, to ensure information access and sharing is working as intended."
Don't get me wrong: all of that sounds very beautiful, but the libertarian that (unfortunately) we all carry within us is compelled to ask: How is this laser-focused supervision going to be carried out at the member state level and how do we ensure that all banks are effectively in the scope of same?

Unless the EBA provides a very good answer to those questions, it is safe to assume that their "four-fold alternative approach" is a perfect regulatory stance for fantasia, a continent where regulators have unlimited resources and are so tech-savvy that they can review the functioning interfaces (the APIs) of all banks from Portugal to Bulgaria. 

But wait, this is Europe, not fantasia. In Europe, the banks have realized that they prefer not to give away their data so easily and banking regulators are very busy keeping us safe from the next economic debacle. The idea that the EBA can live up to its role of ensuring that the banks play by the rules by carrying out increased oversight is a beautiful idea that we should put to the test before we embrace it at the risk of endangering the succesful implementation of the PSD2. 

It is therefore very important that the Fintech world applauds and stands by the decision of the European Commision to challenge the EBA's "Screen-scraping ban". 

Anyone committed to the future of fin-tech should echo the Commision's call to keep Screen-Scraping at least as a fall-back option. We need to make sure that we have some aces under our sleeve in case the banks decide to play too smart. 

Disclaimer: The opinions expressed by the author in this post are strictly personal and do not reflect the official position of the Kreditech Group. Any law-suit threats, hate-mail or angry rebuttals in response to this text are ideally to be addressed to the author directly, in the comments. :)







domingo, febrero 05, 2017

Automated Decision-making, Evil Algorithms and other Latent Dystopias

A brief epilogue to my participation in CPDP 2017

Elvis Presley


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.






Agile, Fintech & Product Management in Regulated Spaces

Red Hamburg Skyline


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.



domingo, octubre 23, 2016

Nuestra Historia, Contada por los vencidos



http://bibliotecanacional.gov.co/proyectos_digitales/historia_de_colombia/index.html


Exceptuados algunos colegios de la élite bogotana, a los Colombianos no se nos enseña nuestra propia historia.  Esta parece ser la premisa que motiva a Antonio Caballero a escribir Historia de Colombia y sus Oligarquías (1498-2017). 

Esta versión de la historia de Colombia, nos dice Caballero, es la historia que no se ha contado: El relato de los vencidos.  Uno que no le pone maquillaje a la desmedida ambición de los conquistadores, al arribismo de los criollos y al brutal pragmatismo de una realeza que no pudo apretar todo lo que abarcó: Ese gran imperio donde no se ponía el sol.

Pero tal vez lo más importante de esta obra que está escribiendo por entregas el siempre incisivo Caballero es que nos hace caer en cuenta de que muchas de nuestras dolencias son más viejas de lo que pensamos.  Que algunos de esos problemas que parecen nuevos son consecuencia de antiguas coyunturas o que han estado ahí casi desde siempre, encarnados antes en la cosmovisión de algún marqués que no era Americano pero tampoco Europeo, en la traición de algún gran señor que no le cumplió sus promesas a nuestros primeros insurrectos.

Se trata de una prosa cuidadosa, escrita en un lenguaje culto pero muy cercano, muy colombiano, adornado con citas muy pertinentes de historiadores, poetas y otros tantos que con sus testimonios ayudan a desenredar el hilo de nuestra historia. Está escrita en un lenguaje sofisticado pero sencillo: Probablemente al alcance de los lectores más jóvenes.  Sería maravillosa como una lectura seminal en el currículum de las clases de historia de cualquier colegio.

Como es de esperarse, Antonio Caballero es implacablemente crítico:  Esta no es, como siempre, la historia de una iglesia y un imperio que intentaron poner freno al horror de la conquista haciéndole caso, entre otros, a los recuentos de un Fray Bartolomé de Las Casas, sino la historia de una iglesia y un imperio que se acostumbraron a ese horror, que lo perpetuaron y lo coadyuvaron a conveniencia.

Es importantísima entonces esta obra porque, sin victimizarnos, nos permite una visión más crítica de la conquista y de nosotros mismos: De esta gente hecha a retazos que somos los colombianos. Es una obra que nos permite un poderosísimo tipo de instropección porque escudriña en el pasado para señalar nuestros más antiguos resabios.

En el momento en el que esta reseña se escribe, la quinta entrega titulada "La desgraciada patria boba" está en circulación gratuita a través del sitio web de la Biblioteca Nacional, que merece grandes elogios por poner en marcha esta empresa literaria que pone una voz tan interesante al estudio de nuestras memorias y que, con suerte, despertará en las nuevas generaciones un renovado interés por saber como es que el río de la historia nos ha traído hasta acá.

Descargue el libro haciendo click aquí.