Merchant Acquiring in Africa: Opportunities in Low-Card, High-Mobile Markets

Core Banking for Southeast Asia's Rural Banks, Cooperatives and Microfinance Institutions: Scalable, Configurable, and Built for Patchy Networks

<img src="https://m2p-website-file.s3.ap-south-1.amazonaws.com/marketing-cms/m2p-blog/2026/10/core_banking_africa_mfb_sacco_banner_2000x1000.webp" alt="Modern Core Banking for Africa's Last Mile" title="" id="qokgwuqmx" width="100%" height="362">Across Africa, much of the work of financial inclusion is done by small institutions. Microfinance banks, SACCOs, cooperative banks and community lenders serve the farmer, the market trader, the teacher and the small business owner, people that large commercial banks often find too costly to reach.These institutions are trusted locally, but most are held back by the same two problems. The first is technology that is either too expensive or too rigid for an institution of their size. The second is the network itself: branches, agents and field officers often work where connectivity is slow, patchy or missing for hours.This blog looks at both problems together, because in practice they are one decision. Choosing a core banking system is also choosing how well the institution will serve customers at the edge of the network. It also explains how M2P's Core Banking System (CBS) addresses both, drawing on what it has already delivered for community-focused partner banks.<h2 class="heading-node" id="ufir6pyhc">The Reality for Microfinance Banks and SACCOs in Africa</h2>Small institutions carry a large share of Africa's everyday finance. Kenya shows the scale. According to the Sacco Societies Regulatory Authority (SASRA), regulated <a class="link" href="https://thekenyatimes.com/business/sacco-lending-nears-ksh1-trillion-as-property-sector-attracts-biggest-share/" target="_blank">SACCOs had 7.87 million members</a> in 2025 and total assets of about KSh 1.21 trillion. Similar roles are played by microfinance banks in Nigeria, savings and loans companies in Ghana, and microfinance institutions across East, West and North Africa.The same SASRA data also shows the strain beneath that growth. In 2025, 61 large SACCOs held 77.62% of the industry's assets, leaving the smaller tiers to compete with far less. SASRA itself has pointed to the need to support medium and small-tier SACCOs, and Kenya's government has encouraged mergers and shared services among smaller societies. Dormant accounts in deposit-taking SACCOs also rose by 15.75% to 1.69 million in 2025, a sign that many members are not being served with products they actually use.For most of these institutions, the core banking system sits at the centre of these pressures:<ul class="list-node" id="5nvh6f7no"><li>Legacy or fragmented systems: Many still run on ageing software, standalone branch databases, or a mix of spreadsheets and accounting packages. Member data is split across branches, and reconciliation is manual.</li><li>High cost of ownership: Traditional cores are priced and built for large banks. Licence fees, hardware, upgrades and specialist staff consume a budget that small institutions cannot spare.</li><li>Rigid product design: Group loans, savings schemes, share capital, dividends and seasonal agricultural credit often need custom development, which is slow and expensive.</li><li>Rising regulatory expectations: Supervisors such as SASRA in Kenya and the Central Bank of Nigeria for microfinance banks expect accurate, timely reporting, stronger controls and better risk management.</li><li>Pressure to go digital: Members expect mobile access, instant transfers and agent services, which a closed legacy core struggles to support.</li></ul>The result is that many smaller institutions spend more on keeping their systems running than on serving members. A modern core needs to reverse that balance.<h2 class="heading-node" id="r29mmru4c">What an Affordable, Configurable Core Must Do for Smaller Institutions</h2>A core banking system for a microfinance bank or SACCO should not be a scaled-down version of a large bank's system. It should be designed around how these institutions actually work. Six capabilities matter most.<h3 class="heading-node" id="2m5g4reor">1. Pricing that scales with the institution</h3>Small institutions need costs that grow with their member base and transaction volumes, not large upfront licence fees. Cloud deployment removes much of the hardware and data centre spend. Shared infrastructure, with each institution's data kept separate, spreads costs further, an approach that fits well with the shared-services model regulators are encouraging.<h3 class="heading-node" id="j6ele12re">2. Products configured, not coded</h3>A SACCO's product catalogue looks very different from a commercial bank's. It may include member shares, non-withdrawable deposits, dividend payouts, guarantor-backed loans and check-off deductions from employers. A microfinance bank may need group lending, weekly repayments and seasonal agricultural loans. A modern core should let staff configure these products, interest rules, fees and limits through parameters, without waiting months for custom development.<h3 class="heading-node" id="ke5xqpxkh">3. A single, accurate view of every member</h3>All accounts, loans, savings and transactions should sit in one centralised, real-time ledger. This ends duplicate member records across branches, simplifies KYC and gives management a reliable picture of the portfolio at any time.<h3 class="heading-node" id="tv0xqn87p">4. Open APIs for digital channels</h3>Members increasingly expect to transact through mobile apps, agents and digital payment rails. An API-first core lets an institution connect to mobile banking, card issuance, payment switches and fintech partners without rebuilding its core each time.<h3 class="heading-node" id="m47eg3zeo">5. Compliance and controls built in</h3>Regulatory reports, audit trails, maker-checker approvals and fraud monitoring should be part of the core, not separate projects. This matters even more for small institutions with lean compliance teams.<h3 class="heading-node" id="tnpfj847s">6. Migration without disruption</h3>Moving years of member data out of a legacy system is the step most institutions fear. The right partner brings proven migration methods and the ability to run alongside existing systems where needed, instead of forcing a risky big-bang switch.<h2 class="heading-node" id="vd76vyooc">Africa's Connectivity Gap and Why It Matters for Core Operations</h2>The second challenge is the network. <a class="link" href="https://www.gsma.com/solutions-and-impact/connectivity-for-good/mobile-economy/africa/" target="_blank">According to the GSMA</a>, almost 1 billion people in Africa, about 63% of the population, were still not using mobile internet in 2025, even though coverage is now widespread. The gap is sharpest in rural areas, where adults in sub-Saharan Africa are 48% less likely to use mobile internet than those in cities. Many who are online still rely on older 3G devices or feature phones.This is exactly where microfinance banks and SACCOs operate. For their operations, the gap shows up in practical ways:<ul class="list-node" id="1z51b51n6"><li>Branches lose their link to the core during outages, and tellers cannot post deposits or check balances.</li><li>Field officers and agents collect repayments in villages and markets with weak signal, so transactions are recorded late or on paper.</li><li>Customers cannot use self-service channels because they lack a smartphone, a data plan or both.</li><li>Reconciliation becomes a daily burden, as late-posted transactions create mismatches between agent cash, customer balances and the ledger.</li></ul>For a small institution, each of these problems erodes trust, adds operational cost and limits growth beyond the branch network. A core banking strategy for Africa has to start from the assumption that connectivity will not always be reliable at the edge.<h2 class="heading-node" id="wawzu7gvk">Designing Core Operations That Hold Up When Networks Don't</h2>There are two broad ways to keep banking running where connectivity is weak. Both have a place, but they lead to very different outcomes for customers and agents.<h3 class="heading-node" id="spf1zztjj">The traditional approach: store-and-forward</h3>In the store-and-forward model, an agent's device captures a transaction offline, stores it locally and uploads the batch when it reaches a network. The core then processes the batch, usually at end of day.This model keeps service going, but it has real drawbacks:<ul class="list-node" id="t5oj2fz25"><li>Late failures: A withdrawal can be approved at the counter and declined hours later during batch processing, leading to disputes and lost trust.</li><li>Delayed settlement: Agents' funds stay tied up until reconciliation is complete, which strains their liquidity.</li><li>Security exposure: Transaction data stored on a device can be lost or compromised.</li><li>Reconciliation effort: Mismatches between offline records and the ledger have to be resolved manually.</li></ul><h3 class="heading-node" id="yxmkvkdvr">The modern approach: real-time, agent-led banking</h3>The alternative is to keep the core always available and move the connectivity requirement to the point where it is easiest to solve. Instead of every customer needing a smartphone and data, a network of trained agents carries the connected device. Customers visit a local agent, authenticate, and complete transactions that are posted to the core instantly.This model has clear advantages for African microfinance and SACCO networks:<ul class="list-node" id="yhjs06e1f"><li>No customer-side barriers: The customer needs no smartphone, data plan or app.</li><li>Instant confirmation: Balances are checked and updated in real time, so there are no late declines.</li><li>Faster agent settlement: Agent accounts are updated as each transaction is posted.</li><li>Simpler reconciliation: One real-time ledger means far fewer mismatches.</li></ul>To make this work, the core must be available around the clock, handle high volumes of small transactions, and integrate easily with agent devices and authentication services. It should also give the institution full control over agent limits, commissions and monitoring.The practical design principle is simple: keep the core always on, and reduce how much connectivity each transaction needs at the edge. The fewer steps that depend on the customer's own device and network, the more reliable the service.<h2 class="heading-node" id="y5kyizhxg">How M2P Has Solved This for Its Partner Banks</h2>M2P has already put the real-time, agent-led model into production for community-focused banks in India, a market with many of the same challenges as Africa: large rural populations, uneven connectivity and customers who are new to formal banking.M2P's Core Banking System is a 24x7 platform built for continuous, real-time processing. Rather than relying on delayed offline batches, M2P helps partner banks reach remote customers through networks of agents who carry out authenticated transactions that are posted to the core instantly.<h3 class="heading-node" id="v0vm5pifo">A cooperative bank reaching remote customers</h3>A cooperative bank in India migrated from its legacy system to M2P's Core Banking System. Many of its customers are senior citizens and less tech-savvy people in remote areas.To reach them, M2P implemented a biometric, agent-led payment service integrated with the core. Customers visit a local agent, authenticate with a fingerprint, and complete their transaction in real time. They do not need a smartphone, data plan, card or PIN. On the day the service went live, the bank onboarded more than 500 agents from remote locations.<h3 class="heading-node" id="hemi4gsln">A rural-focused cooperative bank</h3>Another cooperative bank, focused on lower-income customers in rural areas, also moved to M2P's Core Banking System. The bank had built its rural strategy around mobile field agents who collect deposits in villages, along with RuPay debit cards, a mobile app with instant transfers, and biometric ATM access. A modern core gave the bank a stronger foundation for extending these services.<h3 class="heading-node" id="eqp3dbmls">A small finance bank migrating at scale</h3>Scale matters as much as reach. A small finance bank in India replaced its core banking system with M2P's Core Banking System, migrating 111 branches and over 1.5 million customers.Want to know more about these deployments? <a class="link" href="https://m2pfintech.com/contact-us/?utm_source=cbs-blog&amp;utm_medium=africa&amp;utm_campaign=oct" target="_blank">Reach out to us</a> for detailed case studies.<h3 class="heading-node" id="fyvh6mecb">What this means for Africa</h3>The lessons from these deployments apply directly to microfinance banks and SACCOs in Africa:<ul class="list-node" id="mu9rwod8y"><li>Shift the connectivity burden to the agent, so customers without smartphones or data can still bank.</li><li>Keep the core always on and real-time, so every transaction is confirmed instantly and agent cash stays reconciled.</li><li>Use authentication that customers already have, such as biometrics linked to national ID, instead of relying on cards and PINs.</li><li>Scale the agent network quickly, without adding branches.</li></ul>In African markets, the same model can be connected to local rails and identity systems, such as national instant payment switches and national ID databases, based on each country's infrastructure and regulations.<h2 class="heading-node" id="tt4sbd5o9">Why M2P Core Banking Is a Strong Fit for African Microfinance Banks and SACCOs</h2>M2P's Core Banking System brings together the affordability, configurability and always-on design that smaller African institutions need.<ul class="list-node" id="8c4hodzqp"><li>Modern architecture: Built on microservices, API-first and cloud-agnostic, so institutions can deploy in the environment that suits their regulator and budget.</li><li>Low-code product configuration: New savings, deposit and loan products can be designed and launched quickly through configuration rather than custom development.</li><li>Real-time, 24x7 processing: Every transaction is posted instantly to a single ledger, supporting branches, agents and digital channels together.</li><li>Easy integration: Open APIs connect the core to mobile banking, cards, payment rails, KYC services and fintech partners.</li><li>Built-in risk controls: A pre-integrated Fraud Risk Management (FRM) engine supports secure operations from day one.</li><li>Proven migrations: M2P has moved banks from legacy systems to its Core Banking System at scale, including a small finance bank with 111 branches.</li><li>More than a core: Institutions can add lending, microfinance, cards, payments and KYC capabilities from the same infrastructure partner as they grow.</li></ul><h2 class="heading-node" id="z9usn7t3x">Conclusion</h2>Africa's microfinance banks and SACCOs are central to financial inclusion, but many are held back by systems that cost too much, adapt too slowly and break down where the network is weak. These are not separate problems. The right core banking system can solve both.An affordable, configurable core lets smaller institutions launch the products their members need without heavy custom development. A real-time, agent-led operating model lets them reach customers at the edge of the network without asking those customers to own a smartphone or pay for data.M2P has already delivered this model for community-focused partner banks, with real-time agent networks reaching remote customers from day one. With a modern, API-first Core Banking System and a clear commitment to the African market, M2P is a strong option for microfinance banks and SACCOs ready to modernise.Ready to modernise your core? <a class="link" href="https://m2pfintech.com/contact-us/?utm_source=cbs-blog&amp;utm_medium=africa&amp;utm_campaign=oct" target="_blank">Contact M2P</a> to explore how M2P's Core Banking System can support your institution's growth across Africa.

Core Banking for Africa's Microfinance Banks and SACCOs: Scalable, Configurable, and Built for Patchy Networks

Build vs. Buy for KYC: When In-House Identity Verification Stops Making Sense

KYC for Microfinance: Biometric eKYC in Low-Connectivity, Field-Led Onboarding

<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/marketing-cms/m2p-blog/2026/09/acs_readiness_mena_blog_v4_2000x1000.webp" alt="ACS Readiness: The Step MENA Banks Can't Skip" title="" id="bmihr66ay" width="100%" height="362">Digital card issuance across the Middle East and North Africa is accelerating, driven by a mix of national digital economy strategies, growing e-commerce volumes, and a new generation of digital-first banks and fintechs entering the market. As card portfolios scale, so does exposure to <a class="link" href="https://m2pfintech.com/blog/intelligent-access-control-securing-digital-payments/?utm_source=blg&amp;utm_medium=acs&amp;utm_campaign=4" target="_blank">card-not-present (CNP) fraud</a> — and with it, the importance of getting Access Control Server (ACS) infrastructure right from the outset.Unlike markets where <a class="link" href="https://m2pfintech.com/blog/3d-secure-your-barrier-against-cyber-attacks/?utm_source=blg&amp;utm_medium=acs&amp;utm_campaign=4" target="_blank">3-D Secure (3DS)</a> was added onto legacy systems over time, many MENA issuers have the opportunity to build authentication infrastructure correctly the first time. Doing that well requires a clear-eyed view of what "ACS readiness" actually means before scaling issuance volumes.<h2 class="heading-node" id="c9p10zbvy">Why Readiness Matters Before, Not After, Scale</h2>It's tempting to treat ACS as something to configure once volumes justify it. In practice, authentication infrastructure is much harder — and more expensive — to retrofit once a card program is live and processing meaningful transaction volumes. Issues with challenge flow design, scheme compliance, or risk-engine calibration surface as customer complaints, failed transactions, or chargeback disputes, not as clean engineering tickets.For MENA banks planning to scale digital card issuance, ACS readiness is best assessed across five areas.<h2 class="heading-node" id="a5wx6nrgp">1. Regulatory and Scheme Compliance Alignment</h2>MENA <a class="link" href="https://m2pfintech.com/blog/psd2psd3-and-dora-learnings-for-apac-mea-markets-from-european-regulations/?utm_source=blg&amp;utm_medium=acs&amp;utm_campaign=4" target="_blank">regulators</a> and central banks are increasingly issuing guidance on strong customer authentication, often informed by frameworks like PSD2's SCA requirements in Europe, while also reflecting local market context. Issuers need an ACS platform that:<ul class="list-node" id="gf11gobg0"><li>Supports EMV 3DS 2.x specifications across all schemes the bank issues on (Visa, Mastercard, and regional/domestic schemes where applicable)</li><li>Can be configured to align with jurisdiction-specific regulatory requirements as they evolve</li><li>Provides audit trails and reporting sufficient to demonstrate compliance to regulators and card networks</li></ul><h2 class="heading-node" id="irjrarb14">2. Risk-Based Authentication Calibration</h2>A core value proposition of 3DS 2.x is the ability to authenticate low-risk transactions frictionlessly while reserving step-up challenges for higher-risk ones. This depends on a risk engine that can:<ul class="list-node" id="iryqsxowr"><li>Ingest transaction, device, and behavioral data to make real-time risk decisions</li><li>Perform reasonably well even with limited historical data during early scale-up, and improve as data volume grows</li><li>Be tuned by the issuer's risk team rather than operating as a fixed black box</li></ul>Banks scaling issuance quickly should ask providers directly how the risk engine behaves in the first months of a new card program, when transaction history is thin.<h2 class="heading-node" id="ldgpgozbx">3. Multi-Channel and Multi-Device Experience</h2>MENA consumers transact across a wide range of devices and channels — mobile apps, mobile web, and desktop browsers — often with varying network conditions. ACS readiness means the challenge experience:<ul class="list-node" id="et951us0a"><li>Renders correctly and loads quickly across device types and connection speeds</li><li>Supports authentication methods relevant to the market (OTP, biometric, app-based approval) without adding unnecessary friction</li><li>Is tested against real regional usage patterns, not just reference implementations</li></ul><h2 class="heading-node" id="r8k2q0e4a">4. Multi-Network and Multi-Market Scalability</h2>Many MENA issuers operate — or plan to operate — across multiple countries and multiple card schemes simultaneously. An ACS platform that requires separate integration work per scheme or per market becomes a scaling bottleneck. Readiness here means confirming the platform can:<ul class="list-node" id="g5firhzig"><li>Handle multiple schemes through a consistent architecture</li><li>Extend to new markets without a ground-up re-implementation</li><li>Maintain consistent uptime and performance as issuance volume grows across regions</li></ul><h2 class="heading-node" id="tvpkwx2go">5. Integration with the Broader Fraud and Risk Stack</h2>ACS doesn't operate in isolation. It works alongside <a class="link" href="https://m2pfintech.com/frm-aml/?utm_source=blg&amp;utm_medium=acs&amp;utm_campaign=4" target="_blank">fraud and risk management (FRM) systems</a>, issuer processing platforms, and dispute management workflows. Before scaling, banks should confirm:<ul class="list-node" id="0rm6vx09n"><li>How ACS decisions feed into (and are informed by) the bank's broader FRM capability</li><li>How chargeback and liability-shift data flows back into dispute management processes</li><li>Whether the ACS provider offers this as a connected capability or requires the bank to stitch systems together independently</li></ul><h2 class="heading-node" id="8t3w6uw0j">The Cost of Getting This Wrong</h2>Issuers who scale digital card issuance without a <a class="link" href="https://m2pfintech.com/blog/build-vs-buy-the-real-cost-of-running-an-in-house-acs/" target="_blank">properly readied ACS</a> tend to encounter the same set of problems: elevated false decline rates that push customers away, inconsistent challenge experiences that frustrate mobile users, weaker footing in chargeback disputes, and compliance gaps that surface only during a regulatory review or scheme audit. Each of these is more costly to fix retroactively than to design correctly upfront.<h2 class="heading-node" id="9b1g6wgko">Building Readiness as a Deliberate Step</h2>For MENA banks planning to scale digital card issuance, ACS readiness shouldn't be an afterthought bundled into a broader card processing decision. It deserves its own evaluation — one that tests regulatory alignment, risk-engine performance, device experience, and scalability against the bank's specific growth plans, not just generic vendor claims.Banks that treat this as a deliberate, upfront step are the ones that scale issuance smoothly, with fewer surprises as volumes grow.<hr>M2P Fintech provides <a class="link" href="https://m2pfintech.com/acs/?utm_source=blg&amp;utm_medium=acs-mena&amp;utm_campaign=4" target="_blank">Access Control Server (ACS)</a> infrastructure built for EMV 3DS 2.x, designed to support issuers scaling digital card programs across the Middle East and North Africa. To assess ACS readiness for your card program, <a class="link" href="https://m2pfintech.com/contact-us/?utm_source=blg&amp;utm_medium=acs-mena&amp;utm_campaign=4" target="_blank">get in touch</a> with our team.

ACS Readiness: What MENA Banks Need Before Scaling Digital Card Issuance

<img src="https://m2p-website-file.s3.ap-south-1.amazonaws.com/marketing-cms/m2p-blog/2026/09/m2p_multirail_violet_centered_2000x1000.webp" alt="One Platform. Every Rail. All Your Merchants Covered." title="" id="w6vlef0gi" width="100%" height="362">Merchants today don't accept payments through a single channel — they accept them through all of them. A customer might tap a card, scan a UPI QR code, or pay through a mobile wallet, often within the same store, sometimes within the same hour. For the merchant, this is a checkout convenience. For the acquiring bank or PSP behind that checkout, it's a considerably harder infrastructure problem.This is what the industry calls multi-rail acquiring — the ability to accept, process, and settle payments across different payment rails through a single, unified system rather than a patchwork of disconnected channels.<h1 class="heading-node" id="omzfpvt62">Why Multi-Rail Acquiring Has Become Non-Negotiable</h1>A few years ago, an acquiring bank could reasonably specialize: card acquiring on one system, UPI on another, wallet integrations handled as one-off partnerships. That approach doesn't hold up anymore, for a few reasons:<ul class="list-node" id="pabf08c6v"><li>Payment preferences are fragmented and shifting. Cards remain dominant for certain merchant categories, UPI has become the default for everyday retail in markets like India, and wallets continue to hold share in specific demographics and geographies. Merchants need to support all three to avoid losing sales at checkout.</li><li>Merchants expect one relationship, not three. A merchant onboarding with an acquirer wants a single dashboard, a single settlement cycle, and a single support line — not three vendor relationships stitched together on the back end.</li><li>Regulatory and interoperability requirements keep expanding. Rail-specific mandates (tokenization for cards, UPI's own compliance framework, wallet KYC norms) all have to be satisfied simultaneously, and increasingly, in real time.</li><li>Operational cost adds up fast. Running separate reconciliation, risk, and reporting pipelines per rail multiplies the acquirer's operational overhead and increases the chance of errors at settlement.</li></ul>The acquirers that handle this well aren't the ones with the most integrations — they're the ones that have abstracted the complexity of each rail behind a common, well-architected core.<h1 class="heading-node" id="k1w0amfqv">What "Handling" Multi-Rail Actually Requires</h1>Supporting multiple rails isn't just a matter of adding more payment method logos to a checkout page. A platform genuinely built for multi-rail acquiring needs to solve for several things at once:1. A unified transaction and settlement layer Regardless of whether a payment came in via card network, UPI, or a wallet provider, the acquirer needs consistent transaction data, consistent settlement timelines, and a single reconciliation process. Without this, finance teams end up manually <a class="link" href="https://m2pfintech.com/recon360/?utm_source=blg&amp;utm_medium=mms&amp;utm_campaign=multirail" target="_blank">reconciling</a> three different formats from three different rails.2. Rail-specific compliance without rail-specific silos Cards require PCI-DSS adherence and network-specific tokenization; UPI has its own NPCI compliance and dispute-handling framework; wallets bring their own KYC and interoperability rules. A well-designed acquiring platform builds compliance into the core architecture per rail, while keeping the merchant-facing experience consistent.3. Risk and fraud monitoring that spans rails Fraud patterns don't respect payment method boundaries — a merchant being targeted for card fraud may also see anomalies on UPI. Acquiring platforms need FRM systems that monitor transaction behavior holistically across all rails a merchant uses, not in isolated per-rail silos.4. Merchant onboarding that scales across payment types A merchant shouldn't have to go through separate onboarding for card acceptance versus UPI acceptance. Modern platforms consolidate <a class="link" href="https://m2pfintech.com/kyc-suite/?utm_source=blg&amp;utm_medium=mms&amp;utm_campaign=multirail" target="_blank">KYB</a>, documentation, and risk checks into a single onboarding flow that activates all relevant rails together.5. Real-time visibility for merchants Merchants want to see all their transactions, across every rail, in one dashboard — with clarity on settlement status, fees, and disputes, without switching between tools.<h1 class="heading-node" id="rbns5e89y">How M2P's Merchant Acquiring Solution Solves This</h1>This isn't a theoretical challenge for us — it's one we've built our <a class="link" href="https://m2pfintech.com/merchant-acquiring-solutions/?utm_source=blg&amp;utm_medium=mms&amp;utm_campaign=multirail" target="_blank">Merchant Management System </a>(MMS) around from the ground up.M2P's acquiring platform is designed as a single core system that natively supports cards, UPI, and wallet-based payments, rather than layering rail-specific add-ons onto a card-first architecture. A few ways this shows up in practice:<ul class="list-node" id="cepo0cpxy"><li>Unified merchant onboarding: Merchants onboard once through a consolidated KYB and risk-check process, and are activated across the payment rails relevant to their business — without separate onboarding cycles per rail.</li><li>Consolidated settlement and reconciliation: Transactions across cards, UPI, and wallets flow into a common settlement engine, giving merchants (and the acquiring bank's finance teams) one clean view instead of fragmented, rail-by-rail reports.</li><li>Cross-rail risk and fraud monitoring: Our <a class="link" href="https://m2pfintech.com/frm-aml/?utm_source=blg&amp;utm_medium=mms&amp;utm_campaign=multirail" target="_blank">FRM</a> capability is built to evaluate merchant transaction behavior across all active rails together, so fraud signals aren't missed because they showed up on a different payment channel than the one being watched.</li><li>A single merchant dashboard: Merchants get one place to track transactions, settlements, and disputes — regardless of which rail the customer paid through.</li><li>API-first integration: Banks and PSPs can plug into M2P's acquiring stack through a consistent set of APIs, whether they're enabling card acceptance, UPI QR acceptance, or wallet payments, reducing the integration burden on their engineering teams.</li></ul>The result is that banks and PSPs partnering with M2P aren't choosing between rail coverage and operational simplicity — they get both, from a platform already built to handle the complexity underneath.<h1 class="heading-node" id="aqh526cca">The Direction This Is Heading</h1>As payment behavior continues to diversify — and as new rails or interoperability mandates inevitably emerge — the acquirers best positioned to adapt will be the ones running on infrastructure designed for multi-rail from day one, not the ones retrofitting new channels onto legacy, card-only cores.For banks and PSPs evaluating their acquiring stack, the question worth asking isn't "can this platform support UPI or wallets too?" It's "was this platform built to treat every rail as a first-class citizen?"Ready to simplify multi-rail acquiring for your merchants?<a class="link" href="https://m2pfintech.com/contact-us/?utm_source=blg&amp;utm_medium=mms&amp;utm_campaign=multirail" target="_blank">Talk to our team</a> about how M2P's Merchant Acquiring Solution can help you accept cards, UPI, and wallet payments on one unified platform.

Tag: "Fintech (65)"

Product

About

Compliance

Resources