Getting balances and statements out of Canara ai1

Canara Bank describes Canara ai1 as carrying more than 300 functions behind a single login — a 5-digit passcode for entry and a separate 6-digit MPIN to authorize money movement, per the app's own install guide. For an integrator the useful part is what sits behind that login: a customer's deposit balances, full and mini statements, fixed and recurring deposits, the four transfer rails (UPI, IMPS, NEFT, RTGS), card management, and Bharat Bill Pay records. The question is not whether the data exists. It is which authorized path reaches each piece, and what you get handed at the end.

For the regulated slice — balances and deposit history — India already has a consent rail built for exactly this, and Canara Bank participates in it as a data holder. That is the spine of how we'd reach this app. The surfaces the consent schema doesn't cover get reached through authorized analysis of the app's own session, arranged with you. Below is the data, the route per domain, a worked request, and what lands in your repository.

What Canara ai1 holds for each customer

Drawn from Canara Bank's feature list and the app's screens. Granularity is what an integrator can realistically read once a session or a consent is live.

Reaching the data: the routes that apply

Account Aggregator consent (regulated, for deposit data)

Canara Bank's retail accounts are reachable as financial information through India's Account Aggregator network — Sahamati reports that all major public-sector banks have onboarded as data providers. A licensed Account Aggregator brokers a consent artefact, the bank signs the deposit and term-deposit records, and you receive them digitally signed. This is the durable route: it survives app redesigns because it's an API contract under RBI's framework, not the front end. We register the consent flow and the data-fetch loop against a participating AA; onboarding to an AA is arranged with you during the build.

Authorized protocol work (for app-specific surfaces)

Card controls, BBPS history, scheduled payments and the travel-booking records are not part of the AA financial-information schema. For those we analyze the app's own authenticated traffic under your authorization — the device-binding, OTP, passcode and MPIN chain the app documents — and reproduce the calls that return those records. More work to keep current than the consent route, but it reaches surfaces consent does not.

Native export (fallback)

The app lets a user download statements directly. Where a one-off or low-frequency pull is all you need, parsing that export is the cheapest option and we'll say so rather than over-build.

For most projects the consent route carries the core ledger and the protocol work fills the gaps around it; if your need is purely balances and statements, the AA path alone is usually enough and we'd scope to that.

Consent under the Account Aggregator network

The AA framework is an RBI initiative governed by the 2016 NBFC-Account Aggregator Master Direction, and nothing moves without an explicit, scoped, time-bound consent from the account holder. A consent names the data types, the purpose, the fetch frequency and an expiry, and the customer can revoke it. We build the integration to honour that: requests stay inside the granted scope, the sync respects the consent's frequency and expiry, and consent and fetch events are logged. On the protocol side, access runs under your written authorization for the accounts in question, data is minimized to what the use case needs, and we work under NDA where the engagement calls for it. India's Digital Personal Data Protection Act, 2023 sets the surrounding obligations on handling that personal data; we treat its data-minimization and purpose-limitation posture as the default, not an add-on.

A worked example: a statement pull over an FI consent

Illustrative shape of the consent-then-fetch loop against an Account Aggregator. Field names follow the AA ReST pattern; exact endpoints and the AA you onboard with are confirmed during the build.

POST /Consent            # FIU requests consent, customer approves in the AA app
{
  "consentDetail": {
    "consentTypes": ["TRANSACTIONS", "SUMMARY"],
    "fiTypes": ["DEPOSIT", "TERM_DEPOSIT", "RECURRING_DEPOSIT"],
    "DataConsumer": { "id": "your-fiu-id" },
    "Purpose": { "code": "101", "text": "account monitoring" },
    "FIDataRange": { "from": "2026-01-01T00:00:00Z", "to": "2026-06-23T00:00:00Z" },
    "consentExpiry": "2027-06-23T00:00:00Z",
    "fetchType": "PERIODIC",
    "Frequency": { "unit": "MONTH", "value": 30 }
  }
}

# after the holder approves at Canara Bank (the FIP):
POST /FI/request   ->  { "consentId": "...", "sessionId": "..." }
GET  /FI/fetch?sessionId=...
200 OK
{
  "FI": [{
    "fipId": "CANARABANK",
    "data": [{
      "maskedAccNumber": "XXXXXX4821",
      "Summary": { "currentBalance": "18450.75", "currency": "INR" },
      "Transactions": [
        { "txnId": "...", "type": "DEBIT", "amount": "1200.00",
          "narration": "UPI/canteen", "valueDate": "2026-06-19",
          "currentBalance": "18450.75" }
      ]
    }]
  }]
}
# records arrive digitally signed by the FIP; verify the signature before trusting them.

What lands in your repo

Each engagement is scoped to the Canara ai1 surfaces you actually need, and the output is meant to run, not to sit in a slide deck.

• An OpenAPI/Swagger spec describing the endpoints we integrate — the AA consent and FI calls, plus any app-traffic calls in scope, with request and response fields.
• A protocol and auth-flow report: the AA consent lifecycle and, where protocol work is in scope, the device-binding, OTP, passcode and MPIN chain as confirmed during the build.
• Runnable source for the key reads — balance, statement, deposit list — in Python or Node.js, your choice.
• Automated tests against recorded responses, plus a signature-verification check for FIP-signed data.
• A normalized schema that maps Canara ai1's deposit, transfer and card records into one consistent shape.
• Interface documentation and notes on consent scope, expiry handling and data retention.

What we account for on this build

Specifics of Canara ai1 that shape how we engineer it — handled on our side, not handed to you as homework.

• The app enrolls a device by sending an SMS from the SIM that matches the registered mobile number, then OTP, passcode and MPIN. We document that device-binding so a consented session can be re-established and refreshed without re-running the full enrolment on every call.
• Money movement sits behind the 6-digit MPIN, separate from login. We keep read integrations strictly on the data surfaces and never touch transaction-authorization paths, which also keeps the work cleanly within read-only consent.
• We design the sync around the consent's expiry and fetch frequency so it doesn't silently lapse mid-month — the periodic consent in the example above carries a hard expiry the integration has to renew against.
• Retail and corporate are different apps: Canara Bank ships a separate Canara ai1-Corporate build with maker-checker roles. We scope and map each side on its own because the auth model and records differ.
• When the app front end changes, the AA-routed reads keep working because they ride the regulated contract; the protocol-routed surfaces get a re-check, which we fold into maintenance.

Where integrators put this

• A lender or NBFC pulling a Canara Bank applicant's statements and deposit history over AA consent for underwriting, signature verified.
• A personal-finance or accounting product syncing balances and categorized transactions for customers who bank with Canara.
• A treasury or reconciliation tool matching NEFT/RTGS/UPI outflows against UTR references for a business banking with Canara.

Cost and how we work

A runnable balance-and-statement client for Canara ai1, with its OpenAPI spec, normalized schema and tests, starts at $300 — and you pay after delivery, once you've run it and you're satisfied. If you'd rather not host or maintain anything, we run the integration as endpoints you call and bill per call, with nothing upfront. Either way the build cycle is one to two weeks once scope is set. Tell us the app and what you want out of it — access, AA onboarding and the compliance paperwork are arranged with you as part of the work. Start the conversation at /contact.html.

Screens we mapped against

Public Play Store screenshots used while tracing which surfaces correspond to which records. Tap to enlarge.

Sources and review

Checked in June 2026 against the app's own listing and the primary regulators of India's data-sharing rail: the Play Store description and install steps for Canara ai1, Sahamati's documentation of the Account Aggregator ecosystem and its participants, and the Government of India / RBI material on the AA framework. Specifics that aren't publicly disclosed — exact AA partners, internal endpoints — are not asserted here and are confirmed during the build.

• Canara ai1 on Google Play
• Sahamati — Account Aggregators in India
• Dept. of Financial Services — Account Aggregator framework
• Canara ai1 on the App Store

Mapped and reviewed by the OpenBanking Studio integration desk, June 2026.

Similar apps in the same data neighbourhood

Other Indian banking apps holding comparable account data. Listed because a single integration usually wants to cover several banks the same way; named neutrally, not ranked.

• YONO SBI — State Bank of India's super app; balances, statements, deposits and UPI behind a login.
• HDFC Bank MobileBanking — accounts, cards, transfers and bill pay for HDFC customers.
• iMobile Pay — ICICI Bank's app, with account data, cards and UPI usable beyond ICICI customers.
• Axis Mobile — Axis Bank balances, statements, deposits and card controls.
• PNB ONE — Punjab National Bank's unified app for UPI, transfers, deposits and card services.
• BOI Mobile — Bank of India accounts, balances, statements and the IMPS/NEFT/RTGS rails.
• bob World — Bank of Baroda's banking app covering accounts, deposits and payments.
• Union Bank Vyom — Union Bank of India's app with account overview, transfers and bill pay.

Questions integrators ask about Canara ai1

Does Canara ai1 data come through the Account Aggregator network, or do you read the app directly?

Both are on the table and we pick per project. For deposit balances, term and recurring deposits, the cleanest path is consent through an RBI-licensed Account Aggregator, where Canara Bank acts as the data holder and signs the records. Where you need surfaces the AA schema does not carry — card controls, BBPS history, booking records — we map the app's own authenticated traffic under your authorization instead.

Which Canara ai1 surfaces map cleanly to structured fields?

Balances, mini and full statements, fixed deposits, recurring deposits and standing instructions map to well-defined record shapes, since the AA framework already defines deposit and term-deposit financial-information types. Bill-pay history, credit-card management and the travel-booking flows are app-specific and we normalize those into a schema we hand you with the build.

How do you handle the SIM-and-SMS registration step Canara ai1 uses?

The app binds a device to a registered mobile number with an outbound SMS from the matching SIM, then an OTP, a 5-digit passcode and a 6-digit MPIN, as its install guide describes. We document that device-binding and token chain as part of the protocol report so a consented session can be established and refreshed cleanly rather than re-running the whole enrolment each call.

Is the corporate version covered, or only retail Canara ai1?

Canara Bank ships a separate Canara ai1-Corporate app alongside the retail one, with maker-checker and multi-user roles. We scope retail and corporate separately because the auth model and the records differ; tell us which side you need and we map that one.