Integration paths for FedCorp, Federal Bank's corporate banking app

Federal Bank has run as a live Financial Information Provider in the RBI Account Aggregator network since September 2021, by its own account-aggregator page. That single fact shapes the whole job: for the balances and statements a FedCorp user reads, there is already a consent-backed, regulated channel into the bank, separate from the app. FedCorp itself is the corporate face of that account — multi-user, maker-checker, with intra-bank, IMPS, NEFT, RTGS and UPI movement. A team that wants this data in their own systems needs both halves: the regulated feed for reading, the app session for everything that acts.

What sits behind a FedCorp login

The surfaces below come from Federal Bank's own Corporate FedMobile page and the Play Store description. Each is a real place data lives in the app, not a generic banking checklist.

Reaching the data, the authorized ways

Three routes apply to FedCorp, and they cover different things. We would not pick one and stop.

Account Aggregator consent (read)

Because Federal Bank is already a registered FIP, deposit and current-account information can be pulled through a licensed Account Aggregator once the account holder consents. The consent artefact fixes purpose, fetch frequency, the linked account and an expiry, and it is revocable. This is the durable path for balances and statement history — it is a regulated feed that does not break when the app's front end changes. We arrange the FIU and AA linkage with you as part of the build.

Authorized app-session integration (actions and the rest)

Anything that acts — initiating a transfer, adding a payee through maker-checker, reading scheduled-payment state — sits outside the Account Aggregator scope. Here we work from the app's and web channel's own authorized traffic: the MPIN-backed login, the session token, the statement and transfer calls. It carries more maintenance, since a UI refresh can move endpoints, so we build a re-validation step into the handover. We run this against a consenting account that you control.

Native statement export (the cheap extra)

FedCorp can already download or email an account statement. For a team that only wants a monthly drop, scripting that export is the low-effort option and needs little upkeep.

Put plainly: for reading balances and statements, the Account Aggregator channel is the one we build on first, because it is the consent-backed feed Federal Bank already operates and it survives app updates. For transfers, beneficiaries and the multi-user workflow, the authorized session is the only thing that reaches them. The statement export rides along when periodic files are all that's wanted.

A statement pull, sketched

Illustrative only — exact field names and the token chain are confirmed during the build against a consenting account. The shape shows how the two read paths differ: an Account Aggregator FI fetch versus a replayed app-session statement call.

# Path A — Account Aggregator FI data fetch (read, consent-backed)
POST /aa/fi/fetch
{
  "consentId": "<consent-handle>",        # purpose, expiry, linked acct baked in
  "sessionId": "<fi-session>",
  "fiTypes": ["DEPOSIT"]                    # current / OD accounts behind FedCorp
}
# -> ReBIT-format FI block: Summary (balance) + Transactions[] (dated, signed)

# Path B — authorized FedCorp session (actions + uncovered reads), illustrative
import requests
s = requests.Session()
s.headers["Authorization"] = "Bearer " + token   # from MPIN login + refresh

r = s.post("https://<fedcorp-host>/corp/account/statement", json={
    "accountId": acct,         # one entity's current account
    "fromDate": "2026-05-01",
    "toDate":   "2026-05-31",
    "channel":  "MOBILE"
})
for txn in r.json().get("transactions", []):
    # normalise: postingDate, valueDate, amount, drCr, utr, narration
    write_row(txn)
# maker-checker note: a transfer POST returns status PENDING_APPROVAL
# until a checker user clears it; the client tracks that state, not just 2xx

What lands in your repo

The output is working software plus the documents to run and maintain it, scoped to FedCorp's real surfaces:

• An OpenAPI/Swagger spec for the normalized surfaces — balance, statement, transfer status, beneficiary list — across entity accounts.
• A protocol and auth-flow report covering the MPIN login, token refresh and session lifecycle, plus the Account Aggregator FI-request flow where it is used.
• Runnable source in Python or Node.js for the core endpoints: statement pull, balance read, transfer-status lookup.
• Automated tests that run against a consenting account or sandbox, including the maker-checker pending/approved branch.
• Interface documentation, plus consent and data-retention guidance written to the Account Aggregator and DPDP requirements.

Consent and the rules that bind this data

This is an Indian banking app, so the framework is specific. Read access to financial information runs through the RBI's Account Aggregator system, where the AA itself is an NBFC that moves data but never stores it, and Federal Bank acts as the FIP. The consent record is standardized — purpose, the data requested, fetch frequency, the linked account, a creation and expiry date — and the account holder can revoke it in full or in part. Personal-data handling follows the Digital Personal Data Protection Act, 2023 and the draft rules issued under it; consent-manager duties under that Act are converging with the AA model. UPI and Scan & Pay activity falls under NPCI's scheme rules. Our side of it: access is authorized and logged, consent records are retained, data is minimized to what the purpose needs, and we work under an NDA where the engagement calls for one.

Details we plan around

Two things about FedCorp shape the build more than anything else, and we account for both rather than hand them back as conditions.

• Maker-checker and multi-user roles. A business entity can assign multiple users with maker and checker rights, and can add external users. We map that authorization matrix so a programmatic client submits in the right role — a payout it raises waits for a checker's approval instead of erroring, and the approval state flows through to the consuming system.
• Per-entity rules and transaction limits. Eligibility and limits differ by entity type — proprietorship, partnership, company, society, trust, HUF — and FedCorp publishes hard transaction ceilings (per its Corporate FedMobile page, a QuickPay daily cap of about ₹1 lakh, ₹20 lakh per transfer, ₹50 lakh daily and ₹5 crore monthly). We encode those so test runs and any automated initiation respect them rather than tripping them.
• Consent expiry and front-end drift. On the Account Aggregator side we design the sync around the consent expiry and fetch-frequency so the feed does not lapse unnoticed, and we track revocation. On the session side we add a re-validation pass that flags when a UI release (the kind that recently brought in UPI and MPIN-reset-by-debit-card) moves an endpoint.

Access to a consenting account or a sandbox is arranged with you during onboarding; it is part of what the project sets up, not something to clear first.

Where teams put this

• Nightly reconciliation: statements and transfer status synced into Tally, SAP or an in-house ledger, matched on UTR.
• Group treasury view: balances aggregated across several entity accounts into one cash-position screen.
• Credit underwriting: statement history fetched through the Account Aggregator route, with consent, to assess a borrower.
• Payables automation: payouts queued and raised under maker-checker, with approval and UTR tracked end to end.

Screens we worked from

FedCorp's published store screenshots, used to read the surface structure. Select to enlarge.

What we checked

This mapping rests on Federal Bank's own pages and the Account Aggregator registry, read in June 2026: the Corporate FedMobile feature and limits page, Federal Bank's Account Aggregator page stating it has been live as an FIP since September 2021, Sahamati's FIP–AA mapping for the live ecosystem, and the app's Google Play listing. Compiled by the OpenBanking Studio integration desk, June 2026.

Other business-banking apps in the same orbit

Same category, useful when a single integration has to span more than one bank's accounts. Listed for context, not ranked.

• ICICI InstaBIZ — MSME banking app covering NEFT/RTGS/IMPS, UPI, GST and collections behind a business login.
• HDFC SmartHub Vyapar — merchant and business banking with payments, statements and a services marketplace.
• SBI YONO Business — State Bank's corporate and SME channel for transfers, trade and account management.
• Kotak FYN — Kotak's transaction-banking platform for business payments and approvals.
• neo for corporates by Axis Bank — Axis's corporate digital-banking app for accounts and bulk payments.
• YES BizOnline — YES BANK's corporate mobile banking for fund transfers and account views.
• IRIS Biz by YES BANK — business mobile banking with multi-user transaction workflows.
• IDFC FIRST Bank MobileBanking — covers business-account access, UPI and transfers alongside personal banking.

Questions integrators ask about FedCorp

Does Federal Bank's Account Aggregator link cover the accounts FedCorp users see?

Federal Bank has been a live Financial Information Provider since September 2021, per its Account Aggregator page, so deposit and current-account information can be shared through a licensed AA with the account holder's consent. That covers balances and statement history as read-only data. Initiating a transfer or editing a beneficiary happens inside the app session, not through AA, so those actions are reached a different way.

Can an automated integration respect FedCorp's maker-checker approvals?

Yes. We map the entity's authorization matrix — who is a maker, who is a checker, which external users exist — so a programmatic client submits in the correct role and a payout waits for approval instead of failing. The approval state is carried through to whatever system consumes the feed.

Which Indian rules apply to pulling data out of FedCorp?

Read access to financial data runs under the RBI Account Aggregator framework, with a consent artefact that names the purpose, fetch frequency, linked account and expiry, and can be revoked. Personal data handling follows the Digital Personal Data Protection Act, 2023 and the draft rules issued under it. UPI activity sits under NPCI's scheme rules.

We only want a monthly statement feed for our group entities — is that possible?

Yes. A periodic statement can come from the app's own download-and-email statement function or from a scheduled Account Aggregator fetch, normalized to one schema across every entity. A narrow job like that is usually a one-to-two-week build.

Source for FedCorp's statement, balance and transfer surfaces is delivered from $300, billed only after you have it in hand and it runs as built; the alternative is a hosted endpoint you call and pay for per request, with nothing upfront. A one-to-two-week cycle either way. Tell us the app name and what you need out of its data, and we will scope the rest — start a conversation at /contact.html.