Skip to main content

Ejemplo de uso de una Open Banking API para encontrar las transacciones de mayor cuantía


Advertencia y disculpas previas: ésta es una de las primeras veces que escribo sobre programación en mi lengua materna (castellano/español) porque el 99% de lo que sé lo he aprendido (y practicado) en inglés, por lo tanto, me disculpo de antemano si los términos técnicos empleados no son los correctos o si utilizo términos directamente en inglés para los cuales existe una versión en español.

Las entidades financieras cada vez se parecen más a empresas tecnológicas y hay quien asegura que el futuro de la banca está en las Open Banking APIs 

Pero... ¿para qué sirve una Open Banking API? 
Las Open Banking APIs permiten crear aplicationes basadas principalmente en los datos que posee la entidad suministradora de la API (normalmente un banco).

¿Y quién puede crear esas aplicationes? Entidades o incluso desarrolladores de software individuales que no tienen por qué tener ninguna relación especial con la entidad financiera. Es decir, cualquiera con unos conocimientos intermedios (iba a decir "básicos" pero igual me quedo corto) de programación.

¿Qué tipo de aplicaciones? Todo tipo de aplicaciones, aunque generalmente suelen ser aplicaciones web o para dispositivos móviles.
Por ejemplo, en teoría (y en la práctica) podrías crear tu propia aplicación de online banking o cualquier otra que se te ocurra, las posibilidades son ilimitadas.

APIs públicas del BBVA
Comentario relevante: no trabajo ni he trabajado nunca para el BBVA ni me une ningún tipo de relación especial con el banco, por lo que mi opinión y mis comentarios no están condicionados por ninguna de estas circunstancias.

Cada vez más y más bancos tradicionales así como empresas FinTech facilitan APIs públicas, aquí tenéis una lista informal: enlace

Entre estas entidades destaca el banco BBVA que fue uno de los pioneros en ofrecer este tipo de servicios.
Su oferta de API públicas es de las más maduras e interesantes de entre los bancos tradicionales, así que aprovechando que mi padre es cliente, decidí echarle un ojo y jugar un poco con una de sus public APIs, en concreto la llamada paystats API.

Esta API  ofrece estadísticas agregadas y anonimizadas de millones de transacciones realizadas con tarjetas BBVA y de cualquier otro banco en TPVs del BBVA, de manera que se puede extraer datos como "qué día del mes se realizaron un mayor número de pagos/compras", o "a qué hora se produjo el pico de transacciones", "cuál fue el importe medio", "en qué barrio/zona", etcétera.

De momento mi aplicación (aquí el término "aplicación" es equivalente a "cuenta de usuario" para acceder a las API públicas del BBVA) sólo está autorizada para acceder a la sandbox (el entorno de prueba), cuyas limitaciones son que los datos están restringidos a la Comunidad de Madrid (es decir, todos los códigos postales que empiezan por 28) y al año 2015.

Así que a modo de ejemplo, decidí escribir el código para encontrar las transacciones (pagos con tarjeta) en puntos de venta con el importe más alto en la Comunidad de Madrid durante el año 2015.

La web del BBVA ofrece pedazos de código en diferentes lenguages de programación. 
En mi caso, me centré en Java puesto que es mi lenguaje favorito y me di cuenta que los ejemplos del BBVA utilizan una librería obsoleta (org.apache.http.client) para el caso de uso que nos ocupa.
El uso de este tipo de librerías hace que el código sea más difícil y tedioso de escribir y mantener, por lo que es mucho más aconsejable utilizar alguna de las más recientes librerías que permiten la comunicación a través de HTTP proporcionando un mayor nivel de abstracción, además de facilitar en gran medida el unmarshalling de objectos Java a partir de la respuesta del servidor, recibida en formato JSON.
En el archivo pom.xml podéis ver que utilizo la librería Jersey que es parte del proyecto de código abierto Glassfish.




El código completo está disponible en Github 
Pequeños comentarios (justificaciones/"disclaimer") respecto al código:
- El código es secuencial intencionadamente, he decidido poner el foco en cómo comunicarse con la Web API y no en la eficiencia/rendimiento del código. 
Además, por mi experiencia con la API pública de Twitter, te pueden denegar el acceso si se establecen demasiadas conexiones en un corto periodo de tiempo, cosa que es más probable que suceda si usas multi-hilo
- No he usado "dependency injection" porque el ejemplo es pequeño (con lo que las ventajas de usarla son menores o incluso inexistentes) y además quería limitar las dependencias al mínimo (i.e., no tener la necesidad de usar Spring)

Ejecutando ése código (concretamente esta clase: MaxAmountListProviderRunner.java), se obtiene la siguiente lista de las transacciones de mayor importe (en euros) en la Comunidad de Madrid en el año 2015, por mes y por código postal:




Y ejecutando ésta otra clase: MaxAmountListProviderRunner.java (mismo nombre pero diferente paquete), obtenemos la misma información pero esta vez por cuadrantes geográficos (500m de ancho por 500m de largo), pero sólo para la ciudad de Madrid (al haber muchos más cuadrantes que códigos postales la "cálculo" para toda el área de la Comunidad de Madrid era mucho más "costosa"):



Los datos cuadran excepto por la transacción de 108070,19 euros señalada en rojo que por algún motivo no se muestra en la lista de transacciones por cuadrantes...

Así que fijándonos en la transacción de 90223,77 euros de Noviembre de 2015, podemos ir a Google Maps y usando las coordenadas geográficas del cuadrante, sabemos que la zona donde se produjo esa compra con tarjeta es la siguiente:




Yo no sé mucho de Madrid, pero la zona parece ser donde están ubicadas bastantes tiendas de artículos de lujo por lo que el dato parece tener sentido.

Pues eso es todo, con este simple ejemplo he pretendido mostrar las posibilidades que ofrecen las Open Banking APIs, ojalá más entidades financieras se sumen a esta tendencia e incluso entidades públicas y gubernamentales. Serviría para dotar de mucha mayor transparencia a la administración pública y prevenir la corrupción.
Al fin y al cabo, los datos de la administración pertenecen a los ciudadanos, así que deberían ofrecerse al público en general. 
Se podrían responder a preguntas cómo "¿cuáles fueron los mayores gastos de la conserjería X de la Comunidad Autónoma Y en el mes Z?" o "¿cuál fue el mayor pago realizado con una tarjeta de crédito a cargo de una entidad pública?", de sta forma, casos como el de las "Tarjetas Black" se habrían cortado de raíz, y seguramente muchísimos más del mismo tipo que no conocemos y probablemente nunca se sabrán...
Cabe destacar a este respecto la Fundación Civio por su labor en contra de la opacidad de los datos de la administración pública.

Comments

Popular posts from this blog

Shared Ledger Simulator

I have been interested in the shared/distributed ledger technology (a.k.a. block chain, a.k.a. the magic behind cryptocurrencies) for more than a year already but recently I had finally put real time and effort into it.

And since I believe that the best way to understand something is to get your hands dirty, that is what I have done, after I got a grasp of the core principles (or that is what I thought back then), I decided to code my own shared ledger simulator.

Initially, I also considered to look into the main existing code bases (e.g., the source code of the main/official Bitcoin client/miner or Ethereum's) since they are open source, but seeing code like thisput me off... That file is 3229 lines big!!! Plus it is written in C++.
Do not get me wrong, I truly believe Satoshi Nakamoto (i.e., whoever hides behind that name) is a genius and also a great software developer, but he/she/they for sure did not have readability as their main priority.

I also noticed that some other people h…

Complete (working) code to verify an Android app user phone number through SMS

Update from Thursday September 14th 2017: 
The very same day I posted this (the day before yesterday), I realized that it looked like Google had just made it effectively obsolete


I thought that at least I could claim that I chose a very demanded functionality to blog about, since Google decided to add a new API to provide this very same service.
Even the names are quite similar, I called it "SMS Verifier" and they call it "SMS Retriever".
But after looking into this new Google Services API, I found out that it requires to use a paid third-party service such as Twilio... very disappointing!
So my original post (which follows below) is still relevant after all, since it allows you to verify the user's phone number for free.

Original post: Tuesday September 12th 2017
It was about time for me to give back to the open source community, so I have just pushed the complete (working) code to verify the user's phone number from within an Android app to Github.

When I goo…