EASE 9.0 · Innovation · Digital Channels & API Ecosystem

A Batch File Is Not an Integration

Open banking, Account Aggregator, and fintech partnerships built on modern APIs.
Decisioning exposed as a service, not custom middleware.

Open banking, Account Aggregator, and fintech partnerships all depend on one capability a bank either has or does not: modern APIs that expose the bank's decisioning capability in a form a partner can integrate without months of custom middleware.

The API-Ecosystem Requirement

EASE 9.0's Digital Channels & API Ecosystem category measures whether a bank's core capabilities are exposed as APIs a third party can call directly, rather than requiring a bespoke integration project for every new partnership.

The Path to Progress

The Business Case

The scale argument is no longer hypothetical. Sahamati's own FY26 ecosystem report puts India's Account Aggregator network at more than 500 crore data fetches and 45 crore cumulative consents processed in a single year, across over 1,100 live regulated entities — a shared, real-time data-sharing rail no single bank's bespoke, partner-by-partner integration could replicate at any price. A bank connected to that network at API speed participates in all of that volume; a bank still offering partners a batch file export, delivered overnight, is invisible to it, regardless of how good its underlying credit or fraud logic is.

Source: Sahamati, FY26 Account Aggregator ecosystem report, as reported (Jun 2026).

What any one bank gains from connecting to that rail well rather than badly is competitive and time-based, not a line item. A fintech partner evaluating two banks for the same integration will simply route more volume to whichever one it can actually connect to. The cost of missing this shows up as partnerships a bank was never even shortlisted for, which is exactly why it never appears on a budget line anywhere.

A bank that can only offer a batch file export cannot participate in the real-time fintech ecosystem, regardless of how good its credit logic is.

The Account Aggregator Precedent

This integration already exists in production, not on a roadmap. India's RBI-licensed Account Aggregator network has named, operating consent managers, including Anumati (built by Perfios), CAMSFinserv, OneMoney, and Finvu, and GSTN itself joined the network as a financial information provider in 2022, so a lender can pull consented GST filings the same way it pulls a bank statement. At least one PSU bank is already live on this network, both as a financial information provider and as a financial information user, connected to Anumati, NADL, OneMoney, Finvu, and CAMSFinserv — a working precedent inside the PSU peer set, not a private-bank-only capability.

Every bank already has some APIs, so building them isn't really the decision this category forces. The real question is whether the bank holds its Account Aggregator and fintech-partner relationships directly, or routes them through a middle layer such as Setu, M2P Fintech, or Decentro, each of which offers faster integration in exchange for sitting between the bank and the partner relationship. That is a decision about who owns the customer relationship at the point of integration, not an engineering choice, and it is the one no integration vendor will raise unprompted, since their business model depends on the bank choosing the outsourced option.

Sources: Sahamati certified-entities registry (sahamati.org.in); a PSU bank's public Account Aggregator disclosure; Business Standard, “GSTN now part of AA network to facilitate cash-flow lending to MSMEs” (2022).

Where AI Agents Fit

Role: Enabler

The API is the enabler; the fintech partner's own product is where a customer actually experiences the outcome. Walk through what actually happens when a lending-marketplace partner's app calls the bank's pre-approval API: the same Credit Decisioning Agent that scores an application inside the bank's own mobile app receives the request, perceives the applicant's real-time bureau and Account Aggregator data exactly as it would for an internal customer, decides against the same policy the bank's own credit committee authored, and returns an approve, decline, or refer response with a Reasoning Agent's plain-language explanation attached, inside the same sub-second target, whether the call originated from the bank's own app or an external partner's. There is no separate, thinner decisioning path built for third parties; the fintech partner's customer gets the identical answer, at the identical speed, a bank's own customer would.

That is the decisioning half of the category. The delivery half runs through Appice's own Traffic Manager: the same real-time, policy-bound monitoring loop this guide describes for credit and fraud, pointed instead at channel infrastructure. A push notification, an SMS, a WhatsApp message, and an email each route through a smart router sitting between the bank's single API call and whichever provider is live, not a hardcoded integration to one vendor. Traffic Manager monitors delivery rates continuously and reroutes automatically the moment a provider degrades, before a customer notices anything is wrong. Switching a provider outright, across push, SMS, WhatsApp, or email, takes under an hour with zero code changes and zero customer impact, across 200-plus pre-built connectors spanning FCM, APNs, HMS, Twilio, Sinch, Kaleyra, Gupshup, and 40-plus SMS operators — not the months-long re-integration a single locked-in vendor relationship would force.

Source: Appice open-architecture / Traffic Manager product documentation, appice.ai.

This is the same lock-in argument the Account Aggregator precedent makes about Setu, M2P, and Decentro, one layer lower. A bank that owns its own channel-routing layer is never held hostage by a single SMS or WhatsApp vendor's contract renewal or a mid-campaign delivery-rate collapse. A bank that has outsourced that layer discovers what it gave up only when it tries to leave.

Where This Breaks Down

The most common failure mode is exposing an API that technically works but was never designed for external partners: undocumented edge cases, inconsistent error handling, and rate limits never load-tested against partner traffic. A fintech partner's automated integration cannot tolerate friction the way an internal system can.

The Skeptic's Answer

Exposing a bank's own decisioning engine to external callers sounds, on its face, like exactly the kind of security surface a PSU bank's risk committee would reject outright. Surely it is safer to keep decisioning locked internally and route every partner through a trusted intermediary like Setu or M2P, who absorb that exposure instead.

That framing conflates two different things: exposure and ownership. Routing through a middle layer does not remove the security surface; it just moves it to a vendor's infrastructure the bank does not control and cannot audit as its own, while quietly handing that vendor the partner relationship along with it. The PSU bank already live on the Account Aggregator network above shows the actual answer: a properly hardened, rate-limited, documented API is not inherently less secure than a middle layer — the same control a bank already trusts for its own mobile app, extended outward instead of ceded to someone else.

One Decisioning API, One Delivery Layer, Every Channel

Appice's architecture routes the bank's own mobile app, its branch systems, and any external fintech partner through the identical decisioning API, and routes every outbound message through the identical Traffic Manager regardless of which provider happens to carry it that day. Improve the credit model for one channel and every channel inherits the change the same day; lose confidence in one SMS or WhatsApp vendor and the bank swaps it in under an hour, not at the next contract renewal. A batch file export could never do the first. A hardcoded vendor integration could never do the second.