<img src="https://m2p-website-file.s3.ap-south-1.amazonaws.com/marketing-cms/m2p-blog/2026/10/baas-cover-fraud-loss-ownership_2x1.webp" alt="In a BaaS Stack, Whose Fraud Loss Is It, Really?" title="" id="x6grswgvy" width="100%" height="60">A customer gets defrauded on a neobank app. The app was built by a fintech. The fintech doesn't hold a banking license — it operates under a sponsor bank. The sponsor bank doesn't run the technology stack — that's handled by a Banking-as-a-Service (BaaS) platform sitting in between. The card that was compromised was issued through a program manager. The transaction that moved the money ran over a card network and a processor neither the customer nor, often, the fintech's own support team has direct visibility into.Now ask the obvious question: whose fraud loss is this?In a traditional bank, the answer is uncomfortable but at least clear — it's the bank's, full stop, because the bank is the only regulated entity in the relationship and the customer's contract is with no one else. In a BaaS stack, the honest answer is: it depends on the contract, it depends on which party had operational control at the moment of failure, and in a meaningful share of cases, it depends on who blinks first in the dispute. That's not a regulatory framework. That's a negotiation.This is one of the more uncomfortable open questions in modern financial infrastructure, and it's worth examining directly, because every month that it stays unanswered, more transaction volume flows through stacks where the question hasn't been settled.<h2 class="heading-node" id="7lr4v0tra">The Stack: More Parties Than the Customer Ever Sees</h2>A typical BaaS arrangement for a consumer neobank or embedded finance product involves, at minimum:<ul class="list-node" id="qyifg25jq"><li>The sponsor bank — the regulated, licensed entity whose charter underpins the whole arrangement, legally the entity "providing" the financial service</li><li>The BaaS/infrastructure platform — the technology layer that provides APIs, core banking rails, card issuing processing, ledgering, and often the actual fraud and risk tooling</li><li>The program manager or fintech — the brand the customer actually sees and trusts, who designed the product experience and owns the customer relationship</li><li>The card network — Visa, Mastercard, RuPay, or equivalent, which has its own rulebook on chargeback liability</li><li>The processor — handling authorization and settlement, sometimes a separate entity from the BaaS platform</li><li>Downstream service providers — KYC/identity verification vendors, fraud scoring vendors, dispute management vendors — each potentially a different company again</li></ul>A customer onboarding into this product has a relationship with the fintech brand. Legally, their account is with the sponsor bank. Operationally, their transaction data, fraud scoring, and dispute workflows run through the BaaS platform. None of these three — brand, license holder, and infrastructure operator — necessarily has full visibility into what the other two are doing at the moment a fraud event occurs.This isn't a hypothetical structure drawn up for the sake of argument. It's the default architecture of embedded finance today, in India under the NBFC-fintech co-lending and PPI issuance models, in the US under the sponsor-bank model that's powered most neobanks and embedded finance launches of the last decade, and increasingly across Southeast Asia, the GCC, and Africa as digital-first banking licenses proliferate. The question of who owns fraud risk isn't a corner case. It's the central unresolved question of the entire BaaS category.<h2 class="heading-node" id="jr3nukzcb">Why "The Contract Decides" Isn't a Satisfying Answer</h2>The reflexive answer from most legal and commercial teams is that the contracts between these parties allocate liability, and in a narrow sense, that's true — most BaaS and program agreements do contain indemnification clauses, loss-sharing formulas, and service-level commitments that assign financial responsibility for different fraud scenarios.But this answer breaks down in practice for three reasons.First, contracts are written before the fraud happens, and fraud typologies evolve faster than contract renegotiation cycles. A loss-sharing clause drafted around card-not-present fraud risk in 2022 may say nothing coherent about a 2026 scam where the customer is socially engineered into authorizing their own transaction, moved through a mule account the sponsor bank's own compliance team should arguably have flagged, using a device fingerprint the BaaS platform's fraud engine scored as "unusual" but didn't block. Which clause governs that? Often, none cleanly does — and the parties end up negotiating the specific incident rather than applying a pre-agreed formula.Second, contractual liability and operational control frequently don't line up. The sponsor bank may be contractually on the hook for a category of loss, but the fraud model that failed to catch it was built, tuned, and operated entirely by the BaaS platform, with the bank having limited visibility into its thresholds or decisioning logic. Conversely, the fintech brand — the party the customer trusts and who designed the user experience that may have made the scam more or less likely to succeed — often carries little to no direct financial liability at all, because they're not a regulated entity and their contract with the sponsor bank was deliberately structured to limit their exposure. The party with the most contractual liability is not always the party with the most operational ability to have prevented the loss, and that mismatch is exactly why these disputes drag on.Third, regulators have not caught up to the structure. Most financial regulation — in the US, India, the EU, and most of APAC and MEA — was written with a bilateral mental model: one regulated institution, one customer, one relationship. Outsourcing and third-party risk guidelines (RBI's guidelines on outsourcing of financial services, the EBA's guidelines on outsourcing arrangements, the US OCC and FDIC's third-party risk management guidance) all gesture at the idea that the regulated entity remains accountable for outsourced functions — but "remains accountable" is a supervisory statement about who the regulator will come after, not an operational answer to who absorbs the loss, who built the control that failed, or how four or five companies should coordinate incident response in real time during an active fraud event. The regulatory answer and the commercial answer are different documents, written by different people, for different purposes, and they often don't reconcile cleanly.<h2 class="heading-node" id="xpjxeb4hj">A Concrete Scenario Worth Walking Through</h2>Consider a realistic case: a customer of a BaaS-powered neobank falls victim to a phishing scam and is tricked into authorizing a push payment to a mule account. The transaction passes SCA-equivalent authentication because the customer, under the scammer's instruction, approves it themselves. It passes the fraud model's real-time scoring because the device, location, and amount are all consistent with the customer's normal behavior — the only anomaly is the payee, which was flagged as "new" but not blocked, per the risk threshold the BaaS platform configured by default.Now trace the aftermath:<ul class="list-node" id="y0z893cgh"><li>The fintech brand fields the customer's complaint first, because that's the app the customer opened. It has no direct mechanism to reverse the transaction and limited visibility into the fraud model's decisioning.</li><li>The sponsor bank is the regulated entity responsible for the account and, in most jurisdictions, is the party a regulator or ombudsman will ultimately hold accountable for customer treatment — but it likely didn't configure the specific payee-risk threshold that let the transaction through.</li><li>The BaaS platform owns and operates the fraud model, and may have offered a stricter threshold as a configurable option — one the program never enabled, whether due to cost, conversion-rate concerns, or simply not being flagged as a priority during onboarding.</li><li>The card network or payment rail, if involved, has its own dispute rules, which may or may not cover authorized-but-coerced transactions at all — most do not, by design, since the customer genuinely authorized the payment.</li></ul>Every party in this chain has a partially valid claim that the loss isn't "theirs" alone, and every party also had some sliver of ability to have prevented it. This is precisely why these disputes are frequently resolved through negotiation, internal write-offs, or — worst of all — simply left unresolved, with the customer absorbing the loss because no single party accepts full ownership quickly enough to make them whole.<h2 class="heading-node" id="4cb6t7ab8">Three Structural Reasons This Keeps Happening</h2>1. BaaS is multi-party by design, and no single party owns the full transaction lifecycle. This isn't a bug to be patched — it's the entire value proposition of the model. A bank gets distribution without building consumer product. A fintech gets a banking license without becoming a bank. A BaaS platform monetizes infrastructure instead of owning customer relationships. That division of labor is exactly what makes embedded finance commercially viable — but it also means the full transaction lifecycle, end to end, isn't visible to or controlled by any single entity, which is precisely the condition that makes fraud liability so hard to assign cleanly.2. Regulatory frameworks still presume a bilateral relationship. Virtually every consumer protection and fraud liability regulation on the books — whether it's Regulation E in the US, RBI's customer liability circulars in India, or PSD2/PSD3's liability provisions in the EU — was drafted assuming the customer's financial institution is a single, identifiable, directly accountable entity. These frameworks are only slowly being updated to contemplate multi-party technology stacks, and in the meantime, the gap gets filled by private contracts that were never designed to do the job regulation is supposed to do.3. Commercial incentives push liability downstream rather than toward the party best positioned to prevent the loss. In commercial negotiations between banks, BaaS platforms, and fintechs, liability allocation is a point of leverage, not a principled design exercise. The party with the most negotiating power — frequently the sponsor bank, given its licensing position — tends to push liability toward the parties with less leverage, regardless of which party actually controls the systems that could have prevented the fraud. This produces contracts that are internally consistent and legally enforceable, but structurally disconnected from where operational risk actually sits.<h2 class="heading-node" id="v4aptyex9">What a More Defensible Model Looks Like</h2>None of this means the problem is unsolvable — it means it hasn't been treated as a design question with the seriousness it deserves. A few principles point toward a more defensible structure:Liability should be mapped to operational control, stage by stage. Rather than a single blanket liability clause, BaaS agreements need granular control-mapping: who configures authentication thresholds, who owns fraud model tuning, who monitors real-time alerts, who has authority to freeze a suspicious transaction before settlement. Liability for a given failure mode should sit primarily with whoever had the operational ability to prevent it — not whoever has the weakest negotiating position.Shared, real-time fraud visibility has to replace siloed dashboards. A meaningful share of these disputes exist because the bank, the fintech, and the BaaS platform are each looking at partial data after the fact. A fraud and risk management layer built for multi-party visibility — where the sponsor bank, the program manager, and the infrastructure platform see the same transaction-level risk signals in real time, not reconstructed after a complaint — removes much of the ambiguity about who knew what, when.Incident response needs a predefined, cross-party playbook, not an improvised negotiation. When a scam or account takeover is detected, the question of who freezes funds, who notifies the customer, and who initiates recovery shouldn't be settled contract-clause-by-contract-clause during the incident itself. The institutions handling this well have pre-agreed, tested incident response protocols that span all parties in the stack, triggered automatically by defined fraud signals.Regulators and industry bodies need to keep building multi-party liability guidance, not just bilateral frameworks. Some progress is visible — the UK's Confirmation of Payee and APP fraud reimbursement rules under the PSR, and evolving guidance from US regulators following several high-profile bank-fintech partnership failures, both represent early attempts to address multi-party accountability directly. APAC and MEA regulators drafting open banking and BaaS-specific frameworks have a real opportunity to build this in from the start rather than retrofitting it later.<h2 class="heading-node" id="3weu95n7b">The Bottom Line</h2>The honest answer to "who owns fraud risk in a shared BaaS stack" today is: it's split across several parties, unevenly, inconsistently, and in ways that frequently don't match who actually had the ability to prevent the loss. That's not a satisfying answer, but it's the accurate one, and pretending otherwise — treating a signed indemnification clause as if it resolves the operational question — is exactly how these disputes end up taking months to settle while customers wait for resolution.Getting this right isn't primarily a legal exercise. It's an infrastructure exercise. The institutions that will handle this well are the ones that build — or partner for — fraud and risk systems designed from the outset for multi-party visibility and clear, stage-by-stage control mapping, rather than treating shared liability as something to be resolved after the fact through negotiation.If you're a bank, fintech, or program manager operating in a BaaS stack and this question has come up in a real dispute rather than a hypothetical one, it's worth examining whether your fraud and risk infrastructure actually supports shared visibility and clear control attribution — or whether it's quietly assuming the bilateral model that regulation was built around. <a class="link" href="https://m2pfintech.com/frm-aml/?utm_source=blg&amp;utm_medium=frm&amp;utm_campaign=oct" target="_blank">M2P's FRM</a> system is built for exactly this multi-party reality, giving every party in a BaaS stack visibility into the same transaction-level risk signals rather than reconstructing them after a dispute. If this is a live question for your organization, <a class="link" href="https://m2pfintech.com/contact-us/?utm_source=blg&amp;utm_medium=frm&amp;utm_campaign=oct" target="_blank">reach out to M2P</a> to talk through what a clearer ownership model could look like for your stack.

Who Owns Fraud Risk in a Shared Banking-as-a-Service Stack — and Why Nobody's Really Answered This Yet

<img src="https://m2p-website-file.s3.ap-south-1.amazonaws.com/m2p-website-file/marketing-cms/m2p-blog/2022/05/Artboard-1-copy-8-10.webp" alt="M2P Fintech" title="" width="100%" height="284">Entering card details every time you shop online can be such a tiresome experience. It often plays damp squib, dulling out the thrill of impulsive shopping. In fact, consumers cite this tedious process as one of the primary reasons for cart abandonment.<h2 class="heading-node" id="5e9f">COFT, the savior</h2>This is where ‘Card on File Transaction’ (COFT) emerges as a savior for both consumers and businesses. This functionality pops up on the customer screen, requesting explicit permission to save card details for subsequent payments.As the need to re-enter card detail is eliminated, COFT enables a seamless and convenient checkout process with lesser cart abandonments. It also boosts the chances of recurring impulse purchases.So, the next time you shop for your favorite shoe or that gourmet chocolate bar, you need not enter your card information. Instead, you only need to enter the CVV (the three digits in the magnetic strip) to pay for your purchase.Sounds amazing, isn’t it?We’re sure you can’t wait to understand the techno-functionality behind this incredible system.Here you go!First things first. We’ll cover what COFT actually is. And then, let’s delve into the latest RBI guideline and the mandate’s impact on the ecosystem players.<h2 class="heading-node" id="a695">What are Card On File Transactions?</h2>Card on File transactions are the stored card credentials available with a merchant, payment gateway or aggregator, or digital wallet. Used for future transactions, the card on file will store relevant details in encrypted format except for the CVV number. However, explicit consent from customers is necessary to store card details.The Card on File functionality is a two-stage process.<h3 class="heading-node" id="03af">First Stage</h3>Here the card details are entered for the first time on the website. After authorizing the transactions with two-factor authentication, the cardholder will be presented with an option to save card details for future purchases. If the cardholder opts in, the card details (except CVV) will be saved in an encrypted format.<h3 class="heading-node" id="18f1">Second Stage</h3>In this stage, the cardholder will just enter their card CVV number every time they initiate a transaction. There is no need to re-enter card details.<h2 class="heading-node" id="010c">How RBI’s latest mandate applies to Card on File Transactions?</h2>Reserve Bank of India’s latest mandate has extended the scope of <a class="link" href="https://m2pfintech.com/blog/how-does-payment-tokenization-work/">tokenization</a> to COF transactions. The circular released in January 2019 and August 2021 carried a device-based tokenization framework, and the same has been now extended to COF transactions as well.Meaning card issuers can also offer card tokenization services as Token Service Providers (TSPs), but they will require explicit consent from customers, including Additional Factor of Authentication (AFA). They will also have the control of tokenization and de-tokenization of the card data.Furthermore, the scope of tokenization has been extended to consumer devices such as laptops, desktops, wearables, Internet of Things (IoT) devices. The circular was issued to reinforce the safety and security of card transactions whilst not disrupting convenience.<h2 class="heading-node" id="a412">What is the impact of these latest guidelines on the ecosystem players?</h2>Subscription payments will be impacted as the new guideline requires explicit customer consent even five days before the recurring transaction. There is also a high chance that the customer may end up missing payment notifications and might miss or default on the payment. This guideline implementation must have been completed before 30th September 2021 by Banks.All merchants, banks, payment aggregators, <a class="link" href="https://m2pfintech.com/blog/what-is-a-payment-gateway-and-payment-switch-understanding-the-basics-of-payments-architecture/">payment gateways,</a> and NBFCs must make technical and protocol changes to their current recurring payment functionalities and Card on File data. This structural change will include a significant cost to the players as they must effect a strategic and operational change.With these new guidelines, the merchants will have to rely on the acquiring banks to address the concerns of customer complaints, chargebacks, and so on. Customers may choose to opt for different payment methods if they fail to experience a seamless shopping experience while initiating card transactions.<h2 class="heading-node" id="1529">Tokenization, the security booster</h2>With the introduction of these guidelines, the only remedy available to enhance security is tokenization. It can be used for one-time and recurring payments, thereby freeing merchants from the hassle of storing sensitive data.<h3 class="heading-node" id="e491">So, how does tokenization work?</h3>Tokenization replaces debit or credit card details with a unique set of characters or tokens that will process transactions without exposing the cardholder’s sensitive account details.Here is how tokenization happens.<ul class="list-node" id="decqr9ga3"><li>A credit/debit card is swiped at POS or on an e-commerce website</li><li>The card number will then be transferred to the tokenization protocol</li><li>The system will generate a random alphanumeric string, also known as “Token ”, to mask the original card number</li><li>The token will be routed to the merchant for further processing</li></ul>For example, card-carrying numbers 4781 2345 1235 3391 will be replaced as A2C0 9JUI 8S2F 7GKY when initiating a transaction.The safe and secured digital transaction is now possible with Tokenization!&nbsp;<a class="link au nl" href="https://m2pfintech.com/blog/how-does-payment-tokenization-work/" rel="noopener">Explore more.</a><h2 class="heading-node" id="cbcb">Conclusion</h2>Tokenization will protect card data from hackers as it is extremely hard to reverse the token to access the original card data.Now, there is a paramount need to develop and deploy solutions that satisfy both the cardholder and still be in check with RBI guidelines.<a class="link" href="https://m2pfintech.com/newsletter/">Subscribe</a>&nbsp;to our newsletter and get the latest fintech news, views, and insights, directly to your inbox. Follow us on&nbsp;<a class="link" href="https://www.linkedin.com/company/m2pfintech/mycompany/">LinkedIn</a>&nbsp;and&nbsp;<a class="link" href="https://twitter.com/m2pfintech">Twitter</a>&nbsp;for insightful fintech tales curated for curious minds like you.

Tag: "Guidelines (2)"

Product

About

Compliance

Resources