Cent eeZ carries a whole bank relationship behind one login

Behind a single MPIN-and-biometric login, Cent eeZ exposes a customer's Central Bank of India current and savings accounts, fixed and recurring deposits, retail loans, mutual-fund and NPS holdings, debit-card controls, insurance policies and a reward-points ledger — the omni bundle the bank ships across Android, iOS and the web, as described on its own Cent eeZ page. That breadth is exactly why a lender, a wealth platform or an accounting tool wants a structured feed instead of asking a customer to screenshot a passbook.

The clean part is that India already has a consent rail for most of it. For the regulated bank ledger — balances, transactions, term deposits — the Reserve Bank's Account Aggregator (AA) network gives a standardized, customer-approved path. For the screens the AA network does not carry yet, authorized interface integration of the app's own session reaches the rest. The bottom line: most of what Cent eeZ holds is reachable through a permissioned route, and below is how each piece comes out.

What's behind the login

These are the surfaces the app actually presents, named the way Cent eeZ names them, mapped to what an integrator does with each.

Authorized ways to reach the data

Three routes apply here, and they overlap by design — most builds use two of them together.

Account Aggregator consent (RBI)

India's consent network moves a customer's financial information from the bank, acting as a Financial Information Provider, to a regulated consumer of that data, after the customer approves a consent artefact in an AA app. It reaches the regulated FI types: deposit balances and transactions, term deposits, and a growing set of investment and insurance records, all on the ReBIT schema. Durability is the draw — the format is standardized, so it survives app redesigns. We set up the consuming-side access and the AA connection as part of the build; effort is moderate.

Authorized interface integration

For everything the app shows that the AA network does not carry — reward points, debit-card controls, the insurance and IPO modules, loan EMI detail — we map the app's own session under the customer's authorization: the MPIN login, the OTP step-up and the device-and-SIM binding, then the calls that load each screen. This reaches the widest surface. Durability is medium, because a UI refresh can move fields, which is something the build plans for.

Native statement export

Cent eeZ already generates downloadable PDF and email statements. Where a workflow needs a document of record, we parse those exports directly. Low effort, and a useful cross-check against the structured feed.

For the core bank ledger — balances, transactions, term deposits — the Account Aggregator consent flow is the route I would build first, because it is standardized and does not break when the app changes. The parts the AA network does not serve are reached through authorized interface mapping of the app's session, and statement parsing covers anything that has to reconcile against a PDF the customer can produce. Which mix is right depends on exactly which domains you need, and we settle that during scoping.

What you receive

The handover is built around Cent eeZ's real surfaces, not a generic template:

• An OpenAPI/Swagger specification that normalizes accounts, transactions, deposits, loans, holdings, cards, policies and points into clean REST endpoints.
• A protocol and auth-flow report covering the MPIN login, OTP step-up and device/SIM binding for the interface route, and the consent-artefact and FI-fetch sequence for the AA route.
• Runnable source — Python or Node.js — for the endpoints that matter most: the statement and transaction pull, the deposit and loan list, and the portfolio snapshot.
• Automated tests that run against a consenting account or a sandbox.
• Interface documentation a developer can pick up without us in the room.
• Retention and consent guidance written against the DPDP Act and RBI's data rules.

A statement pull, end to end

Two short illustrations. The first is the AA fetch for the bank ledger; the second is the interface sequence for a screen the AA network does not carry. Field names are confirmed during the build, not lifted from a public spec, and the values shown are placeholders.

# Cent eeZ / Central Bank of India over the Account Aggregator network.
# Shapes follow the ReBIT FI schema; field names confirmed during the build.

POST /aa/v1/fi/fetch
Authorization: Bearer <FIU token>
{
  "consentId": "<artefact the customer approved in the AA app>",
  "sessionId": "<FI data session id>",
  "fiTypes":   ["DEPOSIT"]          # savings + current balances and txns
}

200 OK  ->  normalized into the spec we hand over (values illustrative):
{
  "institution": "Central Bank of India",
  "account":  { "maskedAccNumber": "XXXXXX4417", "type": "SAVINGS" },
  "summary":  { "currentBalance": "37210.55", "currency": "INR",
                "asOf": "2026-06-23" },
  "transactions": [
    { "txnId": "...", "valueDate": "2026-06-21", "type": "DEBIT",
      "amount": "1840.00", "mode": "IMPS", "narration": "..." }
  ]
}
      

# Interface route for surfaces the AA network does not carry
# (reward points, card controls, insurance). Sequence as observed
# during an authorized build against a consenting account:
#   1. POST /auth/login   { userId, mpin, deviceId }   -> challenge
#   2. POST /auth/otp     { txnRef, otp }               -> session token
#      (device + SIM binding validated server-side)
#   3. GET  /rewards/balance   Authorization: <session token>
#                                              -> points ledger
      

Consent, the AA network, and DPDP

The Account Aggregator framework rests on the RBI's NBFC-AA Master Direction, and its governing principle is plain: no financial information moves without the customer's explicit consent, and the entity consuming that data has to be regulated by a financial-sector authority such as the RBI, SEBI, IRDAI or PFRDA. Every fetch is tied to a consent artefact with a stated scope, purpose, fetch frequency and expiry, and the customer can revoke it at any point. That maps cleanly onto how we run a build: authorized access, logged fetches, consent records kept, and an NDA where the engagement needs one.

On the privacy side, the Digital Personal Data Protection Act, 2023 applies, with its implementing Rules notified in November 2025 and a compliance runway that reporting puts around mid-2027. Where a conflict arises, the RBI's sector-specific rules prevail over the general law, so retention and consent design follow both. We keep the data footprint minimal — only the domains you actually need, held only as long as the agreed purpose runs.

Build notes specific to this app

A few things about Cent eeZ shape how we plan the work; all of them are ours to handle.

• The app binds a session to a registered device and SIM during onboarding. We run the interface route against a consenting account on the device it is registered to, so the server-side validation the app expects is satisfied while we test — access is arranged with you as part of the engagement, not a hoop to clear first.
• Whether a given Cent eeZ data type is available over AA depends on Central Bank of India's live FIP status with the connected Account Aggregators. We confirm that against the Sahamati FIP-AA mapping at the start of the build and route any domain that is not yet served over AA through the authorized interface path instead, so the deliverable does not stall on a registry gap.
• AA consents carry an expiry and a fetch frequency. We design the sync around that validity window and refresh cadence so a long-running pull does not quietly lapse, and so the customer's revocation takes effect immediately.
• Public-sector bank apps get periodic UI refreshes. For the interface route we keep the field mappings in one place and re-check them against each new app version, rather than scattering brittle selectors through the code.

Where teams put this to work

• A lender pulling a consented Central Bank of India statement to read income and cash-flow before underwriting, straight off the AA rail.
• A wealth platform folding a customer's Cent eeZ mutual-fund, NPS and deposit holdings into one consolidated portfolio.
• An accounting product reconciling inbound and outbound NEFT and IMPS transactions against open invoices.
• A personal-finance app combining balances, deposit maturities and the reward-points ledger into a single monthly view.

App screens

Screenshots from the Cent eeZ store listing — useful for spotting which surfaces a given build needs to cover. Tap to enlarge.

Other Indian bank apps in the same orbit

Teams rarely integrate one bank in isolation. These same-category apps hold comparable account data, and a unified feed usually spans several of them — listed for context, not ranked.

• YONO SBI (State Bank of India) — banking, deposits, investments and lifestyle behind one login.
• ICICI iMobile Pay — accounts, cards, payments and investments for ICICI customers.
• HDFC Bank MobileBanking — transfers, bill pay and deposits across HDFC accounts.
• Axis Mobile — Axis Bank balances, payments and card controls.
• bob World (Bank of Baroda) — accounts, deposits and loan servicing.
• PNB ONE (Punjab National Bank) — retail banking, deposits and bill payments.
• Union Ease, formerly Vyom (Union Bank of India) — payments, accounts and digital services.
• BOI Mobile Omni Neo (Bank of India) — omni-channel accounts, transfers and investments.
• CANDI (Canara Bank) — deposits, transfers and loan servicing.
• BHIM (NPCI) — UPI payments tied to a linked bank account.

What this is based on

I worked from Central Bank of India's own Cent eeZ page and its Play Store listing for the feature set and login flow, and from the Reserve Bank's Account Aggregator framework material plus Sahamati's FIP-AA mapping for the consent route and FIP status. Reviewed June 2026.

• Central Bank of India — Cent eeZ (official)
• Cent eeZ on Google Play
• Account Aggregator framework — Dept. of Financial Services
• Sahamati FIP-AA mapping

Mapped by the OpenBanking Studio integration desk · June 2026.

Questions integrators ask about Cent eeZ

Does the Account Aggregator route cover everything Cent eeZ shows, or only the bank accounts?

The AA network carries the regulated financial information types — deposit balances and transactions, term deposits, and increasingly mutual-fund, NPS and insurance records. Reward points, debit-card controls and a few app-only screens sit outside it, so those are reached through the authorized interface path instead.

How do you handle the MPIN, OTP and SIM-binding that Cent eeZ uses at login?

We map the authentication sequence under the customer's authorization against a consenting account on its registered device. The auth-flow report documents the MPIN login, the OTP step-up and the device-and-SIM binding so the integration establishes a valid session the way the app's own client does.

If a customer revokes consent, what happens to the data already pulled?

An Account Aggregator consent artefact carries a defined scope, purpose and expiry and can be revoked by the customer at any time. We build revocation handling into the sync and keep retention data-minimized and aligned with the DPDP Act and RBI guidance, so a revoked consent stops further fetches and the stored footprint stays only as long as the agreed purpose.

Can you ship the statement-and-transaction pull first and add the rest later?

Yes. A common first cut is the account, balance and transaction pull on its own; deposits, loans, portfolio holdings and insurance get layered on once that is running, usually inside a one-to-two-week cycle.

The first thing you usually get is a running statement-and-transaction pull you can call against a consenting account; the spec, the auth-flow report, the endpoint source, the tests and the docs follow from there on a one-to-two-week cycle. Source-code delivery starts at $300, billed only after it is in your hands and you have confirmed it runs. Prefer not to host anything yourself? The same endpoints are available pay-per-call — you hit our API and pay per request, with nothing upfront. Tell us the app and what you need from its data at /contact.html and we will scope it; access and the compliance paperwork are arranged with you as the project runs.