Unrequited?

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:

  1. A mechanism to request API or programmatic access to an account.
  2. A mechanism for account holders to confirm, deny and revoke requests for API or programmatic access (in fact, these concepts should be unified).
  3. A call-back, triggered when customers confirm, deny or revoke access, along with a token for use when accessing the account.
  4. 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.

Thanks for this feedback Renen, and for taking my call now and being open to meeting with the Investec team so that we can talk through your points :slight_smile:

It’s really useful to get candid feedback from people in the community who are building things and we really appreciate the effort people in the community are going to to build things and give us useful feedback.

Looking forward to the chat!

I am happy to say that a couple of days ago I chatted to the Investec team behind the Programmable Banking initiative. I came away a lot more positive. They are not blind to the challenges presented by the current platform – and appear to be actively addressing those shortcomings.

I concluded that it might better to consider the current state of the product as an “MVP” rather than as a “toy”. Certainly, Investec expressed a coherent vision as to how the product, and their engagement with the community, will be shaped into the future.

I’d be surprised if the limitations we encountered now are still challenges six months from now. The initiative holds enormous potential and I certainly hope that they can deliver on their aspirations.

1 Like