When Investec launched its Programmable Banking product last year, they must have had Devin Pearson in mind. A developer working in the API space for more than 15 years, he has been an active member of the Programmable Banking Community and consistently provides product feedback to the Investec team. “I was already an Investec customer, but once I got involved with Programmable Banking, I became quite vocal in the community and started giving feedback on ways to improve the platform,” he says.
Devin has also focused his attention on building out Programmable Banking API tools that make it easier for fellow community members to interact with and use the API.
APIs drive everything
All movement of data between mobile and desktop apps needs to happen through APIs. “These days people should be building for an API first,” says Pearson. This will make development of an online portal or an app that much easier, seeing that all the business logic is situated in one place. “As the world changes, we’re going to see more companies building with APIs, between departments and customers,” he says.
Consistency in Data
When Devin first started looking at the Investec API he had some ideas around making the platform more user-friendly and unifying the data in line with industry standards.
This included addressing inconsistencies in lower- and uppercase letters, and standardising the way that lists are encapsulated, he explains. “Trivial as it may seem”, says Pearson, consistency in the data is important because this will affect adoption of your API. “I tried to give that outsider perspective,” he explains.
“Financial products should be simple,” Pearson says. Most of the data Investec returns is relatively simple and self-explanatory, he notes, and where it’s not, it’s a work in progress. Unifying the data through an API can help button down these grey areas in the data sets, as Investec is doing.
While every payment may look the same to the end user, what often isn’t apparent is that under the hood there is a lot of complexity that needs to be addressed depending on the type of payment and from which account the payment is made. “There are many hoops to jump through in terms of business process, regulatory requirements, authorisations and permissions,” he says. For example, some business payments require a multi-step authorisation process to be settled, and multi-user access and permissions can affect who and how much can be paid from an account. “Investec has done a good job of simplifying it.”
Conforming APIs to a general standard
It’s worth spending time and looking at what’s being done across the industry before setting off in your own direction, especially if you’ve been at it for many years. Devin recommends that you don’t reinvent the wheel when it comes to APIs unless what you are driving really requires reinvention.
To developers building in the API space, Pearson says to look at the APIs of companies you use every day, the likes of Twitter and Spotify, for example. “See how these interactions work. It will give you a good understanding of best practices and ways to build a solution that conforms to what’s out there.”
“Tools like Postman are helping standardise certain styles of APIs,” Pearson explains. “I think it’s great, because the world is changing and we’re moving more to APIs," he says. “The more people stay within those lines, the easier it is to integrate these tools. Sometimes people forget. They want to make a very bespoke solution but that makes it difficult to integrate.” It is important to remember that if you don’t keep to standard, every developer has to spend time figuring out the nuances of your API in order to use it.
To help with standardisation, Devin has created an Investec Programmable Banking Postman Collection, which is actively used by Programmable Banking community members wanting to use the Investec API.
Building a sandbox
Another developer tool that Devin has built is a mock server that pretends to be the Investec API, and allows users to build a solution in a sandbox environment and test certain scenarios. “If you’re not an Investec client or you want to put out a solution that makes far more API calls than you normally do, the mock server allows for the embedding of fake transactions,” Pearson explains.
For example, say, you have a personal account and you’re doing 50 transactions a month but want to test a system that handles 200,000 a month, the system will enable you to test this.
It’s a Node.JS app that largely runs on the command line interface (CLI), with a SQLite database for transactions. “A super easy tool” that connects to a restful API, says Pearson. Using Postman, an API platform, he also built a collection of connectors to quickstart the tool. “It connects to the mock sandbox API and the Investec API, which are carbon copies of the other,” he explains.
Coming from a background in PHP and Rust, building an API in Node.JS, using ExpressJS for the framework, turned out to be simpler than Devin expected and he was able to “get something going quickly,” he says. “Building the mock server has given me an intimate understanding of the Investec API and has been really useful in enabling community members to test and demo their solutions without having to use their own sensitive financial data.”
Get involved in the Programmable Banking Community.
If you have questions or want to say hi to the Programmable Banking Community core team, you can mail us [community-investec@offerzen.com], and we will get back to you.
If you want to see what the community has been up to, you can:
- Join the community
- Browse the community’s open-source projects
- Read the dev docs
- See more demos
- Read other programmable banking-related blog posts
