Banking-as-a-service · embedded finance
Your product on top. A regulated entity underneath. Both accountable.
Embedding accounts, cards or loans in your product doesn't make you a bank. It makes you a partner of one, or of an NBFC, a PPI issuer or a payment aggregator. Three questions define every embedded product:
Who holds the money?
The regulated entity, almost always.
Whose brand does the customer see?
Yours first, but rarely only yours.
Who answers when something goes wrong?
You first, with the partner's obligations behind you.
- Your productApp, website, brandWhat the customer seesCustomer journeyFirst-line supportYour own terms
- Technology layerYours, a provider's, or the partner'sAPIsLedgersDashboardsReconciliation
- Regulated entityBank, NBFC, PPI issuer, payment aggregatorWhere the money sitsLicence or authorisationKYC obligationsCustomer fundsComplaints escalation
- Payment systemsUPI, IMPS, NEFT, RTGS, card networksMoving money between institutions
What banking-as-a-service actually is
Banking-as-a-service, or embedded finance, is a partnership model. A regulated entity (a bank, an NBFC, a PPI issuer or a payment aggregator) provides a financial product, and a business that isn't regulated for that product offers it to its own customers inside its own app or platform, usually connected by APIs.
The appeal is obvious: a marketplace can offer its sellers accounts and payouts, a payroll app can offer salary cards, a B2B platform can offer credit at checkout, without spending years becoming a regulated institution. The catch is just as clear: the regulated entity's obligations don't go away, and a good part of them flows through to how you build and run the product.
Not a shortcut around regulation
The regulated entity provides the regulated product and stays responsible for it. What you do around it (onboarding, marketing, support) may carry its own obligations, set by the rules for that product and by your agreement.
Not the same everywhere
Models described from other countries, where a platform can hold customer balances in its own name, don't carry over automatically. Each product has its own rules in India.
The layers, and who usually owns what
Every embedded product has the same four layers, whatever it's called. The division between them is what your partnership agreement is really about.
| Layer | Usually owns | Typical questions |
|---|---|---|
| Your product | The customer relationship, design, onboarding screens, first-line support | What do we promise customers, and in whose name? |
| Technology layer | APIs, the ledger that tracks balances and transactions, dashboards, reconciliation | Is the ledger ours, a provider's or the partner's? Which is the record of truth? |
| Regulated entity | The licence or authorisation, KYC obligations, customer funds, regulatory reporting, grievance escalation | What will the partner require from us, and audit? |
| Payment systems | Moving money between institutions under each system's rules | Which rails does the product use, and through whom? |
What can be embedded, and who provides it
Each product sits on a different regulated entity and a different set of rules. Before designing the experience, name the entity type behind each feature, because it decides what's possible.
Bank accounts
Provided by: A bank
Opened by the bank under its KYC rules. Your product can host the journey; the account is the bank's.
Collections
Provided by: A bank or payment aggregator
Virtual account numbers, UPI and cards into accounts the regulated entity controls.
Payouts
Provided by: A bank or authorised provider
Paying out to customers, sellers or staff from a funded account.
Wallets and prepaid cards
Provided by: A bank or authorised PPI issuer
Limits and KYC levels set by RBI's PPI rules; co-branding under the issuer's policy.
Credit cards
Provided by: A bank or permitted NBFC
Co-branded cards must carry the issuer's branding; the partner's role is limited.
Loans and credit lines
Provided by: A bank or NBFC
You may act as its lending service provider; the lender stays fully responsible.
Guides to each: current accounts, virtual accounts, payouts, prepaid cards, corporate cards, working capital.
Who embeds what
The best embedded products solve a money problem the platform's users already have inside the platform. The product follows from the users, not the other way round.
| Platform | Users' money problem | Products that fit |
|---|---|---|
| Marketplace | Sellers wait for settlements and juggle cash | Seller payouts, collection accounts, working capital through a lender |
| Payroll or HR software | Employees paid once a month; expenses reimbursed late | Salary payouts, prepaid expense cards |
| B2B software for a trade | Invoices chased by phone; buyers want credit terms | Collection links and accounts, buyer credit through a lender |
| Gig or delivery platform | Workers want pay quickly and often | Frequent payouts, prepaid cards |
| Distribution network | Retailers and agents need stock credit and cash services | Credit lines through a lender, banking correspondent services |
How the economics usually work
Embedded products earn in a few ways: fees your customers pay for the product, a share of what the regulated entity earns from it, or indirectly, through customers who stay and spend more because the platform does more. Costs run the other way: the partner's fees, the technology layer, and the compliance, support and reconciliation work on your side, which is easy to underestimate.
Some revenue arrangements have disclosure rules of their own. For co-branded cards, for example, RBI's card directions require the revenue sharing between issuer and partner to be indicated to the cardholder and shown on the issuer's website. Assume customers may see how you earn, and design the product so that's comfortable.
Revenue
Customer fees · partner revenue share · more engaged users
Direct costs
Partner fees · per-transaction and API charges · cards and delivery
Hidden costs
Compliance staff · support · reconciliation · audits
Your brand, but not only your brand
“White-label” suggests the customer never sees the provider. For regulated products in India that's rarely true, and the rules say so directly for some of them.
Co-branded credit and debit cards
RBI's card directions require the card to say it's issued under a co-branding arrangement and to carry the card-issuer's branding prominently. The partner can't market it as its own product, and the issuer's name must appear in all marketing. The partner's role is limited to marketing and distribution and giving access to its goods or services; it doesn't see transaction information, and the issuer is liable for the partner's acts.
Co-branded prepaid instruments
RBI's PPI directions let issuers co-brand under a Board-approved policy that sets out each partner's roles and obligations. The partner must be a company incorporated in India, or a government department.
Embedded loans
Under RBI's Digital Lending Directions the lender must publish its lending apps and service providers on its own website, send the Key Fact Statement and loan documents on its own letterhead, and remains fully responsible for what its service provider does.
Summarised from the RBI directions listed under Sources. A summary, not legal advice.
Following the money
The most important diagram in an embedded product is the fund flow: where money goes when a customer pays in, where it sits, and how it leaves. In almost every model, customer money should sit with the regulated entity, in accounts it controls, and not pass through the platform's own company accounts.
For lending, RBI has made this explicit: disbursal goes to the borrower's bank account and repayment goes directly to the lender, with no pass-through or pool account of a service provider in between. Other products have their own rules, and the partner will tell you what its model allows.
| Question | Why it matters |
|---|---|
| Which account does customer money land in? | Decides who holds it and who is responsible for it |
| Does money ever touch our own accounts? | Usually it shouldn't; if it does, the rules for that must be clear |
| What's the record of each customer's balance? | The ledger and the bank must agree every day |
| How do refunds and reversals flow? | They're where fund flows most often break |
A worked example: a marketplace adds seller payouts
A marketplace for handmade goods wants to pay its sellers automatically after each delivery, instead of by manual bank transfer once a month. It doesn't want to hold sellers' money itself. Walking through who does what shows where the real work is.
| Step | Marketplace | Regulated partner |
|---|---|---|
| Seller signs up | Collects details in its own onboarding screens | Sets the verification standard and may run the checks |
| Buyer pays | Shows checkout under its brand | Collects the payment into accounts it controls |
| Order delivered | Tells the partner the order is complete | Holds funds until the agreed release point |
| Seller paid | Shows the payout in the seller dashboard | Pays out to the seller's verified bank account |
| Something goes wrong | First contact for the seller or buyer | Handles escalations under its own obligations |
| Month-end | Reconciles orders, fees and payouts | Provides statements and reports |
Illustrative. How funds are held and released for a marketplace depends on the partner's authorisation and the rules for that model; see the marketplace payments guide.
Obligations you'll carry anyway
The regulated entity holds the licence, but it will pass many requirements to you through the agreement, and check you meet them. Plan for these from the first design, not after the partner's review.
Partner due diligence
Regulated entities review partners before and during the relationship. Expect questions on your security, finances and people.
KYC journeys
You'll often host the screens, but to the partner's standard and under its rules.
Data handling
Personal and financial data under India's data protection law, the product's rules and the partner's requirements.
Marketing claims
What you may say about the product, and whose name has to appear.
Complaints
First-line handling, timelines and escalation to the partner.
Audit access
The partner, and possibly the regulator, may need to inspect how you run your part.
Which obligations apply to your model is a legal question; take advice before signing.
From idea to launch
The API integration is rarely the long part. Agreeing who does what, and satisfying the partner's review, usually takes longer, so start those conversations first.
- 1Define the productWhat customers get, and which regulated product sits underneath each feature.
- 2Choose a partnerOne whose authorisation covers what you want to offer.
- 3Agree responsibilitiesFund flows, KYC, branding, support, data, audits: in writing.
- 4Pass due diligenceThe partner's review of your business and controls.
- 5Integrate and testIn the partner's test environment, including failures and refunds.
- 6Launch smallA limited group first; watch reconciliation and complaints closely.
Questions for a prospective partner
- 01Which authorisation or licence covers each product we want to offer, and can we see it on the regulator's list?
- 02Where does customer money sit, and does it ever pass through our accounts?
- 03What must appear in our app and marketing about you?
- 04Which parts of KYC do we run, to what standard, and who keeps the records?
- 05How are complaints handled between us, and within what timelines?
- 06What happens to customers and their money if our partnership ends?
Risks worth planning for
An embedded product depends on someone else's licence, systems and appetite for risk. That's a fair trade for speed, but it needs a plan.
Partner concentration. If one partner stops a product, what happens to your customers? Know the exit terms.
Rule changes. Regulators revise directions; products built at the edge of a rule are the first to need rework.
Ledger drift. If your ledger and the partner's disagree, customers see the wrong balance. Reconcile daily.
Reputation. Customers blame the brand they see. Your support has to be able to fix things, not just forward them.
Where Peneu fits
Peneu isn't presented here as a bank, and this page doesn't claim that Peneu holds any banking licence or authorisation. Which products Peneu can help you embed, with which regulated partners, how funds flow and how responsibilities are divided, is confirmed during onboarding.
Banking-as-a-service questions
What is banking-as-a-service?
An arrangement where a business that isn't a bank offers financial products (accounts, payments, cards or loans) inside its own product, with a regulated entity providing the product underneath. The business designs the experience; the regulated entity provides the regulated service.
Does embedding banking products mean I don't need a licence?
It means the regulated entity you partner with holds the licence or authorisation for the product it provides, and remains responsible for it. Whether what you do around it needs its own registration or authorisation depends on your activity. That's a legal question to settle before you launch.
Can I fully white-label a card or a loan?
Not entirely. RBI's card directions require a co-branded credit or debit card to say it's co-branded and to carry the card-issuer's branding prominently, with the issuer's name shown in all marketing. For digital loans, the Key Fact Statement and loan documents go to the borrower on the lender's letterhead, and the lender lists its lending apps and service providers on its own website. Your brand can lead; the regulated entity's can't disappear.
Who holds my customers' money?
The regulated entity providing the product: the bank for an account, the PPI issuer for a wallet or prepaid card, the lender for a loan. Customer funds shouldn't pass through your own company's accounts unless the product's rules and your agreements specifically provide for it.
What does embedded lending involve?
A regulated lender (a bank or NBFC) makes the loan; a platform acting as its lending service provider may handle parts of the journey. RBI's Digital Lending Directions say the lender remains fully responsible for what its service provider does, and set rules on disclosures, fund flows, data and grievances.
Who handles customer complaints?
Usually both: you as the first point of contact, since the customer knows your brand, and the regulated entity, which has its own grievance redress obligations and escalation to RBI's complaint system. Agree the process and timelines in the partnership before launch.
How long does it take to launch an embedded product?
It depends on the product, the partner's review process and how much compliance work your side needs. Partner due diligence, agreements, integration and testing all come before launch. Ask a prospective partner for its steps, not just its API documentation.
Does Peneu provide banking-as-a-service?
Peneu isn't presented here as a bank or as holding any banking licence. Which products Peneu can help embed, with which regulated partners, and how responsibilities are split, is confirmed during onboarding.
Official sources
- RBI — Master Direction: Credit Card and Debit Card – Issuance and Conduct Directions, 2022 (updated 7 Mar 2024)Co-branding: disclosure, issuer branding, partner's limited role, issuer liability.
- RBI — Master Directions on Prepaid Payment Instruments (updated 27 Dec 2024)PPI co-branding arrangements.
- RBI — Reserve Bank of India (Digital Lending) Directions, 2025 (8 May 2025)Lender responsibility for service providers, disclosures, fund flows.
Last reviewed . Examples, amounts and screens marked illustrative are not Peneu figures.