59. BaaS (Part 2)

Aditya Kulkarni
Auth-n-Capture
Published in
7 min readJun 10, 2021

--

Hope you have read the previous part… (here)

If not then here is a quick recap… we started with burgers and ended with banking products… BaaS (Banking as a Service) model is wherein banks offer their products (accounts, deposits, cards, lending products etc.) and services (collection and disbursement) to customers (SMBs, corporates, retail customers) via third parties (Payment Aggregators, Neo banks, merchants) by externalising APIs while keeping control on compliance & governance… that, in a nutshell, is known as BaaS (2/2 points for writing about BaaS in one line with lot of commas)

Let’s move to the next point which I lightly touched upon in the earlier chapter

Third Parties

As mentioned, these are entities who are interested in extending banking products. Some of the usual suspects are:

A. Payment Aggregator (PA):

PAs have built their businesses on the bank’s collection (Payment gateway, recurring payment, UPI etc.) and disbursement services. PG is a decade old story and payout is out of there for a few years. So BaaS is not new to them. But PAs definitely want to use BaaS to extend their portfolio of services and offer related banking products to their merchants.

Illustration 1

In a regular Payment Aggregation, a PA will facilitate PG payments from customers and do settlements to merchants. But in the BaaS model, a PA will provide additional banking products (refer above illustration) to merchants. These offerings can be explicit or implicit.

Explicit Offering:

  • Opening current account for the merchant during sign up for PG solution
  • Issue credit card (E.g. RazorPay X Card)

Implicit Offering: (Bake the banking product into their core offering)

  • Early settlement offered by some PAs is nothing but credit to the merchant and recovered from the next settlement cycle (Refer this article)
  • Overdraft facility to do vendor payout and adjust amount from next settlement

As a Payment Aggregator knows its merchants better (Settlement cycles, settlement amount, vintage of business etc.), they can position the products as per the merchant’s requirements.

B. Neo Banks:

These FinTechs offer banking products/services without being a bank or having branches. As we know, there is no silver bullet for all the problems and for everyone. So, the Neo-banks target specific demographics or cohorts such as couples, families, teens, women, freelancers, SMEs etc.

Neo-banks take standard products from the bank(s) and then stitch features that address problems of their customer base and add value to their customers.

I recommend you to check their websites to understand how they are different. How they have built their products and positioning products to their target customers. Few names: Open, Jupiter, Fi, Fampay (will update few more names here)

Remember, these are not real banks and they can’t call themselves ‘banks’ as restricted by Section 7 of the RBI’s Banking Regulation Act of 1949.

C. Merchants/Corporates:

Anyone who has a captive user base or vendors or even service providers, can offer banking services to them. These can be Lending Techs, WealthTechs, FoodTech, Travel OTAs, eCommerce marketplaces or even Corporates

Let’s take an eCommerce marketplace. Like any business, money comes in and money goes out. Here is how the money flow looks like; these are the standard scenarios that a merchant is catering to, with the help of banks or payment aggregators.

Illustration 2: Standard Model

But when you look from BaaS point of view, there are a lot many other opportunities emerge.

Illustration 3: BaaS opportunities

A merchant/corporate knows its customers, vendors and partners better than anyone. So definitely they can do a better job at selling banking products to them. Again, they may choose to do this explicitly (e.g. issuing co-branded credit cards to its users), implicitly (e.g. extend line of credit to the vendor and collect from next sales proceeds).

Let me rephrase the statement — any merchant/corporate can become FinTech… but the road to achieve this may vary. Here is a simple chart to show it.

Illustration 4: Corporate mapping (Brain behind: Ram)

The transition is simple for Digital ‘heavy’ companies but it may take longer time for traditional & non-finance companies but it is very much possible if they want to head in that direction.

Example:

  • MoneyTap (a digital lending company) transitioned to Freo (Neo bank)
  • Flipkart’s own Buy Now Pay Later (BNPL) product
  • Groww (Investment platform) offering Fixed Deposit

A merchant or Corporate can directly work with the banks or use Payment Aggregator’s services to offer banks’ products or use API provider/TSP to enable the services.

D. API Providers/TSP:

These entities unify APIs of bank(s) and then offer to third parties (PAs, FinTech or merchants). They help the third parties with faster GTM and play an important role in ‘build Vs. buy’ decisions. TSPs are not one stop shop — Some are super specialised in what they offer. Also TSPs add tremendous value if the products are complex (e.g. Hyperface.co)

What do these third parties know or do which a bank cannot?

“That is a very good question” (pat on your back). Banks have been around for centuries… I am sure they know how to sell their products, and definitely over decades, they would have learnt a thing or two about their customers. Let us not make the mistake of assuming that banks are monoliths and slow entities.

Before we answer above question… let me list strengths of these third parties:

  1. Technology: These companies will invest in technology that is aimed to deliver better user journeys, custom features, dashboards and analytics.
  2. Accessibility: Some of these entities (Merchants and payment aggregators) already have existing users, so distribution is simple (i.e. customer acquisition cost is lower).
  3. Data: Merchants/PAs are sitting on a lot of customer, vendor and merchant data. This data can be leveraged to make decisions when it comes to customising product features, lending decisions etc.
  4. Brave: These third parties have an appetite to take risks which a bank may not have. These entities are ready to challenge norms and ready to invest big bucks (thanks to funding) and capture the market faster.

Now, the answer to the above question is: Banks want to leverage these capabilities of third parties to fuel their own growth. Just like how McD doesn’t mind using food delivery Apps to sell ‘more’ burgers.

Plus banks also keep doing what they do best. They won’t close down their own distribution network (branch, Apps etc.)

All fancy… but why do it?

  • There is a market which is underserved (in terms of distribution, product, experience, pricing etc.) — so there are definitely growth opportunities
  • Someone has more data/info than the other — so work together to increase the size of the pie. E.g. a bank has money to lend but a marketplace knows its sellers better. Thus, this data can help banks to underwrite correctly)

I have saved the best one for the last…. Money

Banks share revenue (revenue sharing models, referral model etc.) with the third parties. So these parties can create a substantial revenue stream from these services. For some entities this is the main revenue (e.g. Neo banks) but for few it can be an additional revenue channel (e.g. eCommerce merchants)

Note: Check the URLs of these Neo-banks — Jupiter.money, Fi.money, Open.money (See… they know why they are in this — not sure if referring to customer’s, bank’s or investor’s money but definitely there is money :))

Interesting… How much money?

This is where it becomes tricky… Revenue share depends on various factors:

  • Responsibilities of parties (distribution, customer on-boarding, support)
  • Risk (who is underwriting — in case of credit)
  • Bargaining power of the parties

Payments, banking, FinTech is a game of ‘scale’… the more the active customers, the more the volume if more the volume, more revenue. And companies can bring down costs to increase the profit (if the idea of a company is to ‘generate profit’)

Embedded Finance

I am sure you might have heard this jargon. Without getting too much into details, in simple words, embedded finance is about offering (or embedding) financial products (e.g. UPI, insurance, credit line) in the user journey.

Examples:

  • While booking international ticket, enable users to buy travel insurance
  • While sending invoice to your buyer, create virtual account for the buyer so they can pay against it (for easier reconciliation)
  • On-board user on BNPL product while doing the purchase
Illustration 5 — embedded BNPL registration

What is new about it?

Mostly, nothing… This has been done for years but as a cross-selling. But in embedded finance, you will offer them as part of integrated user flow. So ‘the new’ part is reimagining the product, process and user journeys while taking care of compliance and risk.

It is more complicated than I made it look like as there are a set of different processes that need to be embedded without distorting the user’s original journey. Otherwise, users will neither book a ticket nor buy your insurance.

The future:

Market size, smartphones, internet penetration, data, AI/ML and custom requirements of customers… everything is coming together but most importantly, finally we have come to realise that while banks are a bit boring, they make money (most of the time)… So everyone wants to look like a bank and sell banks’ products & services to make money.

Still, a word of caution, there is one thing banks fear is compliance and risk. So it is the responsibility of these third parties (FinTechs, merchants, TSPs) not to deviate (cut corners) for the sake of growth as one’s mistake may cost others or the entire ecosystem.

I feel this space is exciting, exhausting, boring and interesting… all at the same time… I hope to learn more and write more about these things.

--

--

Aditya Kulkarni
Auth-n-Capture

Trying to follow Richard Feynman’s words “do what you can, learn what you can, improve the solutions, and pass them on”.