At Apidays Singapore 2022, Todd Schweitzer Co-founder & CEO at Brankas, presented a keynote on Commercial models for Open Finance in South East Asia. Here is a summarized version of Todd’s keynote. There is also a link to the recording of Todd’s presentation.
In South East Asia, Open Finance happens differently. Without any regulatory requirement, Open Finance is led by industry. There are no regulations for banks to provide data API’s. The bottom-up innovation has happened from banks, non-bank lenders, e-wallets and fintech in identifying and scaling new commercial models that are driven by API-based financial services.
The purpose of sharing this is to trigger new ways of thinking about how Open Finance/ API Banking can actually be a new business driver for fintechs and even traditional financial institutions.
When we talk about Open Finance/API Banking, most people immediately think of customer data and enabling customers to link their bank account to a financial services app or a budgeting app. That was the starting point in Europe with the Account Information Service Provider (AISP) model, and that's often the starting point for Open API products in South East Asia.
The above screenshot is from Lloyd's Bank in the UK and this is the common perception of Open Banking. Frankly it's a bit hard to understand if there's even a business case here; it benefits the consumer but is there a way to monetize this? It's a difficult case to make.
So I open my Lloyd's Bank account, I tap the Open Banking button, I see a menu of the banks available, I agree and consent to link my accounts and then I can see my Barclays, Santander and Natwest bank account data inside my Lloyd's app. As a starting point it's pretty simple, but not exciting commercially.
But when you look at statement data on the corporate side it starts to get value adding very quickly. For example, in Singapore Brankas uses UOB for some of our corporate banking activities, and UOB now has an integration with the Xero accounting app. So we can have instant reconciliation whenever there's a debit, credit or any other transaction activity that passes through. We don't need to download data from our bank accounts then upload it to our accounting platform; it's all matched seamlessly so that we can have real-time reconciliation. The ability to link external bank accounts is a valuable part of our Xero software subscription.
There are even more exciting and commercially attractive API-based products that we're already seeing in South East Asia. These include:
Whether it's retail payments so that you can pay by bank at your e-commerce store or top up an e-wallet from inside the e-wallet app.
This is an example of a Philippines account, where inside the GCash e-wallet app we can link our UnionBank account, authorize the debit of that account, and a pull payment into a GCash wallet, all from within the GCash app.
What is valuable here for banks offering a retail banking API, is that it's a zero-marginal-cost product. You can allow merchants to receive funds into their account at the same bank without funds leaving the bank. The willingness of merchants to offer a pay-by-bank service is very high, as their other options are working with a payment gateway or a payment intermediary that is settling at T+7 (seven days) maybe and they're charging 2-5% total transaction costs, especially because transactions here are often low value in South East Asia.
The ability of the banks to provide a direct payment by bank API is massively valuable and consumers prefer it. In SE Asia, 80 % of the eCommerce transactions of consumers are using some version of bank transfer.
Retail payments API is a low-hanging fruit for banks to instantly monetize transaction fees and offer it as a transactional banking solution.
Banks can make a corporate disbursements API available, which can be plugged into a corporate customer's Enterprise Resource Planning (ERP) system. This replaces the CSV upload and batch upload processing that we're probably all used to.
This also removes the need for an intermediary in the transactional process. The direct debit of corporate accounts can be made possible with a fairly simple user interface.
If you're a lender, this can also be brought into your Loan Management System, so that as soon as a loan is approved, you can trigger an automated disbursement. It can also be used in insurance for paying out claims, or for paying out agent commissions. All this can be automated without the need for an intermediary.
We're seeing more and more banks bring their payment processing in-house.
We're also seeing conglomerates, in this example JG Summit, a large conglomerate in the Philippines, looking to bring their payment processing in-house as a solution that they can offer to sister companies within the conglomerate group, as well as any corporate banking client directly.
They can offer it directly because if you're already an acquirer, if you already have a bank relationship, you already have your standard QR, you even have some of your fintech partners, in JG Summit's case like GrowSari, you can enable in-house payment methods, and then most of the transaction volume is "on us". So you don't need a payment processor, and you can offer a full customer checkout page or a payment link entirely as an in-house solution by connecting payment APIs and offering that as a bundle.
We're seeing more and more banks bringing in-house their payment gateway facilities to offer that as an API product to their corporate banking clients.
One illustrative example that we're seeing more and more is enabling a customer's custodian account, whether that's an exchange or some other mechanisms where you can use the crypto in your exchange to top up an e-wallet to pay at checkout, and you can choose between your different methods, or your different assets, that are held in custody by the exchange.
In the same way you pay-by-bank, you can also authenticate with your exchange, and the exchange can then do the trade and then disperse to the merchant immediately.
We're seeing more and more examples of not only supporting cash-in and cash-out to an exchange but actually using your exchange account as a payment mechanism externally.
This is an example from Singapore, where Singapore has a national ID and authentication method called Singpass. Initially for government services, Singpass has now expanded so you can use your Singpass to register and login to financial services. In this example you can use your Singapore to login to your OCBC banking app, so you don't need to generate a new password and username and registration details. You can onboard immediately using your Singpass without going through the same Know-Your-Customer (KYC) process all over again.
In most of South East Asia there is no national online identity check mechanism. For each fintech or bank to do Know-Your-Customer (KYC) checks all the way from the start results in a massive drop in conversion. It's a massive obstacle in the customer onboarding journey, and we're seeing new ways to do identity and authentication.
In markets like the Philippines or Vietnam or Indonesia, where there isn't a centralized way to do KYC we're seeing more examples of of banks and e-wallets that are offering their identity and authentication for KYC customers "as-a-service" to third parties, so that those third parties don't have to do KYC from scratch.
Account opening is a key part of a financial services flow. It could be a retail savings account, a crypto exchange, a loan origination or a Buy-Now-Pay-Later (BNPL) account. We're seeing standardized APIs that can be surfaced on third-party apps to trigger account origination.
GCash is a good example where they have a tie-up with CIMB, which in the Philippines is a digital-only bank. Most of the customer acquisition happens inside the GCash wallet app. A GCash wallet app user, fully KYC'ed, can use it to open a savings account in just a minute powered by CIMB.
This is beneficial to GCash as they have more activity inside the app and they can get to see customer data more robustly. It's great for the CIMB bank as customer acquisition is quite easy now just by enabling this API.
Visa and Mastercard in particular have been quite aggressive already in Asia-Pacific in thinking beyond the traditional cards business, about new ways to do issuing and new use cases for one-time or specific-use card numbers.
The third-party card issuers can offer an end-to-end account opening app or API that lives inside a third-party site. For a large purchase on a travel website, one can apply for a Visa credit card and agree to share data, and get instantly approved by the card issuer for a line of credit which can be used directly.
A virtual Visa card can be used to pay for that large travel purchase. This all can happen on the checkout page of a travel website. The issuer bank might later send a physical card for showcasing other products as well. A Visa credit card can be activated at the point of purchase right when needed.
Tons of activity here in BNPL consumer financing, SME financing and merchant lines of credit on e-commerce. We're also seeing salary advances. These are all being developed as third-party APIs that can be surfaced on a third-party app that is much closer to the end user than if the financial institution were to build out that product and distribution entirely on their own.
Tokopedia is a good example of this API usage. It is the largest marketplace in Indonesia, known for inventory financing lines of credit for sellers of their platform.
Based on seller history & rating (aka seller metrics), different financing companies will offer a line of credit upon qualification. In minutes. Sellers can apply and get approved to get funded for credit for inventory. Everything happens inside the merchant page of Tokopedia.
This process is seamless and provides ease for sellers. This is a great example of providing lending as a service and working with fintech partners to do origination and servicing on one’s behalf using potential borrowers' data.
This helps to transfer the manual process of banking loans, which are prone to fraud, to a very transparent process. This allows for instant loan re-generation, instant disbursement, and payment based on seller metrics of Tokopedia. The benefits from a customer acquisition cost point of view are far higher than the traditional process for banking as well.
We've seen a lot of exciting neo-brokerages and retail investment and fractional stock trading applications. We're starting to see those being surfaced on third-party apps, whether I go to the Robinhood-equivalent in Indonesia or the Philippines, very soon we'll see where you can access Robinhood-type neo-brokerage products on your digital bank app or on your e-wallet app, or even as part of an e-commerce or travel app.
Last is an API marketplace where financial institutions can offer third-party financial products inside the bank's ecosystem to the bank's customers; building a third-party marketplace where they can start generating platform fees.
Starling Bank, based in the U.K., is an interesting example of it. It's a digital-only bank that has built a marketplace of APIs from third-party apps inside the Starling Bank ecosystem. A retail or business customer can access dozens of creations inside a Starling Bank app or instantly available on those apps like Xero, Quickbooks, pension, or HR schemes.
For Starling, rather than focus on building branches or being vertically integrated inside their app, it's better to provide integrations with other financial services & adjacent businesses, to provide an experience where a Starling Bank customer might not even open the starling app anymore. A customer might interact with a Starling account every day, since that account is fully integrated in real-time with apps a customer does use every day.
It's an interesting way to think about financial systems not as an "owned" channel but as infrastructure that can live inside a third-party enterprise or retail app.
Banking-as-a-Service is quite new in South East Asia, which is why a lot of these examples are U.S. and European-based, but it gives a flavor of where the market is heading. In the chart, the companies on the left are all licensed financial institutions that offer their bank products as APIs, and the cross-border clients are the apps where those financial products live.
For example, with TransferWise (now Wise), when I keep a U.S. dollar balance, that U.S. dollar balance on the Wise app is actually sitting at Community Federal Savings Bank (CSFB), which is a very small thrift bank in New Jersey. I would never bank with Community Federal Savings Bank otherwise, but because I can keep a U.S. dollar balance that is a CFSB account white-labeled by Wise. You can imagine how much volume and the size of deposits that CFSB has gained just by providing that distribution mechanism to Wise. The same with Cross River and with Metrobank, the earnings that they've received from powering the likes of Marqeta, Stripe and Revolut is massive. It's a fascinating use case, and we will be seeing more and more of that.
We are just starting to see Banking-as-a-Service in South East Asia, and will see more of it in the future. This is where we see local banks looking to offer their products as APIs and not by building branches. Relying on distribution via APIs.
Why Banks choose to adopt API commercial models:
The new API banking stack is:
Observations on adoption curve:
And yet many financial institutions are still in the "wait and see" mode:
But for those who think that API Banking is early in South East Asia, bear in mind that this is changing very quickly....
Watch Todd's full presentation here:
Todd's slide deck is available at:
Brankas is an Open Finance enabler across South East Asia: Indonesia, Philippines, Singapore, Thailand, Vietnam and more to come. Brankas' key activities are:
Brankas' participation in Open Finance: