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

Kafka + WebSockets + Angular: event-driven microservices all the way to the frontend

In the the initial post of the  Event-driven microservices with Kafka series (see here  or  here ), I talked about the advantages of using event-driven communication and Kafka to implement stateful microservices instead of the standard stateless RESTful ones. I also presented the architecture and the source code of a related proof of concept application. In this post, I would like to show how to extend the asynchronous event-driven communication all the way from Kafka to the Web frontend passing through the Java backend. Hence, in the first post of this series, we got rid of HTTP as the communication protocol among microservices in the backend, and now we are also replacing it (with WebSockets) as the communication protocol between the frontend and the backend. Ok, but why would you do that? Because it provides a better experience to the end user!. Using WebSockets you can build legit  real-time user interfaces, the updates are pushed immediately from the server to the client

Cómo pedir cita previa en la DGT y desesperarse en el intento

El uso de la tecnología para la agilización de la administración española es simplemente bochornoso (y me quedo corto). Además todo el mundo lo sabe, sin ir más lejos, la última gran chapuza  informática en el Ministerio de Justicia va a costar al menos  60 millones  extra.  Pero como el dinero sale del bolsillo de los ciudadanos, pues aquí no pasa absolutamente nada y nadie asumirá ninguna responsabilidad. Esta es la triste realidad de la España actual. Pero es que hasta un trámite tan sencillo como pedir cita previa en una de las Jefaturas Provinciales de Tráfico desespera hasta al más templado. Y como quiero ser muy específico y una imagen vale más que mil palabras, a continuación voy a documentar todo el proceso que es de todo menos intuitivo. Todo empieza abriendo este enlace Y como podéis ver en la imagen previa, con la primera pantalla (vamos a obviar que la interfaz parece que ya haya cumplido la mayoría de edad, tiene pinta de ser de finales de los 90) llega la pri

Proof of Social Network Identity: a proof of concept

One of the main criticisms to blockchain technology is based on the huge consumption of electricity required by the biggest networks (e.g., Bitcoin and Ethereum). That huge electric power consumption  comes from using Proof of Work (PoW) algorithms to prevent " double spending " which is closely related to the " 51% attack ". Some other types of algorithm have been developed as an alternative to PoW, the more popular one being Proof of Stake (PoS), which basically implies that individuals with higher stake (i.e., more crypto money) have more power (i.e., are more trusted) than the rest. Hence, PoS, creates an entry barrier for those who want to become members of the blockchain network, since one needs to own a stake in order to join the network. The key to prevent " double spending / 51% attacks"  is to use something  in the block validation mechanism which is complicated or expensive enough for some malicious actor to replicate or to clone or