With access to historical data and an ability to dynamically intercept, assess and block individual transactions in real time, the Investec Programmable Banking initiative is super exciting. There are a number of direct commercial applications for the technology within my business, and, at a personal level, it’s just flat out fun.
However, scratch lightly and you’ll walk squarely into some pretty dramatic, and non-obvious, shortcomings. For example, we wanted to use an Investec account to trigger automated receipt processes, and, more recently, as part of your hackathon project, we had hoped to leverage your “Programmable Card” mechanism to manage card transactions. Beyond a basic PoCs, neither is practically possible.
Our automated receipting work floundered because transactions that don’t originate from a card interaction, don’t get surfaced to the programmable banking interface. You can work around this by polling the account’s transaction history. But this is a terrible approach: in general, polling simply can’t scale.
Our Hackathon work has also been challenged by limitations inherent to the platform. You can’t dynamically provision Programmable Card logic (or even API access). The API’s simply don’t exist. Every customer has to login to their individual account, enable programmable banking, and then cut and paste the code into the right place. If there is any doubt: this is not scalable. Forget persuading individual customers to do this: if you wanted to configure a few hundred cards for a fleet of truck drivers to use to buy fuel, you’d have to manually configure each card.
As a fun, toy project for individuals, Investec Programmable Banking is a great idea. But, the limitations of the program are not made clear. Your team glibly proposed IFTT extensions as possible Hackathon projects. For yourself, easy. But, there is a vast difference between code built to scratch one developer’s itch once, and commercially scalable solutions.
I’m forced to conclude that as currently conceptualised, this program is not a catalyst for innovation. It’s a toy, most appropriate to once off transaction logging applications.
For this program to spawn commercially interesting outcomes, developers have to be able to programmatically provision before and after transaction logic, and to request API access. Specifically, we need:
- A mechanism to request API or programmatic access to an account.
- A mechanism for account holders to confirm, deny and revoke requests for API or programmatic access (in fact, these concepts should be unified).
- A call-back, triggered when customers confirm, deny or revoke access, along with a token for use when accessing the account.
- Programmatic ability to load before and after event handling code.
In the interim: I strongly suggest you rebrand this as the toy “Investec Toy Programmable Banking” program.