Breaking new ground in the way banks and third parties collaborate, Digiata put the new Nedbank Open Banking APIs to the test.
By Johan Kühn, Director at Digiata
At Digiata, we pride ourselves on our curiosity and love of problem-solving, and our ability to embrace the new and unknown, so when Nedbank proactively released a set of application programming interfaces (APIs) in March 2019, we leapt at the chance to experiment and play with them.
The Open Banking wave is building momentum, notably thanks to new regulation such as PSD2 in the EU encouraging banks to release their hold on customer data and banking functionality. The intention is to drive innovation and competition in banking and an increase in financial services options – things that we and our client Nedbank solidly support.
Although similar regulation has not been created in South Africa yet, Nedbank reacted to the open banking shift in the market by releasing a number of secure APIs aligned with open banking standards, enabling third parties to partner with the bank to develop innovative new digital solutions.
The first series released, included APIs for Authorisation, Payments, Customer details, Personal Loans, Account data, Rewards, Open Data, Branch list and Bank list.
We decided to focus on the Payments API, since businesses are often faced with various choices and uncertainty when they want to accept payments from customers.
Nedbank promises that the API allows you to: “Start sending and receiving money today with our secure transfer fund capabilities that will grow your business and attract more customers.” It also says that you can “move funds in no time.”
We decided to put that to the test by developing a solution that shows how the Payments API can be used to allow a merchant to take a payment from a customer in realtime.
Our most significant discovery was that the Payments API only allows one payment at a time. Multiple payments or bulk payments cannot be processed via the Payments API currently. This makes the API more suited to single POS, websites or mobile sales.
Because our corporate clients typically do large volume and high value transactions this unfortunately, means that for the moment, the Payments API is unlikely to be suitable for them. And so, for the immediate future, we will continue automating these transactions using existing host-to-host (H2H) interfaces and ISO 20022 message standards.
Additionally, we noticed that there are some inconsistencies in the APIs. The APIs use various methods to read values, for instance, json body post parameters, query parameters and form data. On the other hand, interfacing with a bank using web services and a structured universal standard is ground-breaking.
More generally, the support of the Nedbank team was excellent. Because everyone is experimenting with the environment and possible use cases, the API support crew is no doubt inundated with newbie questions. They were great at providing good support and channels for interaction.
Our next step will be to experiment with the Accounts API, which we think could be very useful and applicable to our customers. This API provides real-time account details, account balance and transaction details.
The account balance information could be used to power intraday realtime decisions for sound cash liquidity management solutions such as driving top-ups, sweeps or funding transfers.