Where Bankit's account data lives, and how an integrator gets at it

Bankit MFB rides Nigeria's NIBSS Instant Payment rails — the same instant-transfer fabric every Nigerian bank settles on — and surfaces the customer view through an Android and iOS app, a web banking portal (per the bank's announcement in early 2025), and a Verve debit card the user can manage in-app. The integration question is not whether the data is there; it is how to reach it under a Nigerian open-banking regime that was approved for August 2025 launch and is still rolling out operationally as of mid-2026.

The short version: balance, statement, transfer history, bill-payment ledger and card metadata are all behind the authenticated mobile and web channels; outbound flows piggyback on NIBSS NIP. The honest current route is authorized interface integration of those channels, with the CBN's consent pipe (OBCMS, operated by NIBSS) wired in as it lights up for Bankit. The build accommodates both without forcing a rewrite mid-cycle.

Nigeria's open-banking regime, as it stands

The Central Bank of Nigeria issued the operational guidelines for open banking in 2023 and approved the framework's go-live for 1 August 2025, per TechCabal's reporting at the time. The August date did not produce a nationwide cut-over; the regulator moved to a phased, registry-driven rollout, and industry observers expect the bulk of operational go-live to land across 2026. Two pieces sit at NIBSS: the Open Banking Registry (OBR), which lists verified participants, and the Open Banking Consent Management System (OBCMS), which records and revokes a consumer's data-sharing permissions against a standardized API operated under apis.openbanking.ng.

For a Bankit-specific build, this means the consent layer has a target — biodata, account details, transaction history and debit mandate, as named by the OB standard — but the wire is live only for participants that have completed enrollment. We track Bankit MFB's registry status as part of the build, treat OBCMS as the long-run pipe, and run the integration against the authorized interface route in the interim so the customer is not waiting on a phased rollout. The CBN framework is the dependable forward-looking piece; the consumer's direct authorization is what makes the read defensible today.

What lives behind the Bankit account

Routes to that data we actually use

CBN Open Banking via OBCMS consent (long-run)

Where Bankit MFB is enrolled in the Open Banking Registry, the consumer's consent is captured through OBCMS with an OTP step on the consumer's registered phone or email, and the agreed scopes — biodata, account details, transaction history, debit mandate — return through the published Open Banking API standard. Technical posture is RESTful, OAuth 2.0, TLS. This is the route the framework was built for; we wire to it as Bankit's enrollment becomes operational.

Authorized interface integration of the mobile + web channels (day-one)

Under written customer authorization, NDA and per-request audit logging, we map the Bankit Android build and the web portal: capture the auth handshake (phone + PIN + OTP, device fingerprint), isolate each customer-visible screen as a stable internal call, and stand up a normalized schema across balance, statement, transfer, bill-payment and card endpoints. Compliance posture mirrors what the CBN guidelines require of OB participants — consent recorded, data minimized, retention bounded — so the same audit trail carries forward when the workload moves to OBCMS.

User-consented credential access (narrow footprint)

For single-consumer use cases — a treasurer reconciling one MFB account, an underwriting check on one applicant — the consenting consumer drives an authenticated session under our supervision, we ship the script and the consent log, and the surface area stays as small as the customer needs.

For most Bankit engagements, the interface-integration route is what runs in production today; the OBCMS path is wired alongside it so the cut-over is a config change, not a re-engineering.

What ships at the end of the build

• OpenAPI 3.1 specification covering the agreed Bankit surfaces — accounts, statement window, transfer (with NIP name-enquiry preflight), bill payment, card status — versioned and ready for codegen.
• Runnable source in Python and Node.js for the auth handshake (phone + PIN + OTP, device registration, refresh), the read paths, and one outbound NIP funds-transfer path with name-enquiry validation.
• A protocol & auth-flow report: token shape, refresh cadence, device-binding rules, NUBAN/bank-code normalization for the MFB tier, error-code table.
• Automated tests against a consenting account or a sandbox arranged during onboarding, including a re-validation suite for when the portal front end shifts.
• Interface documentation written for an integrator stepping in cold — endpoint reference, field-level notes, retention guidance aligned with the CBN guidelines and Nigeria's data-protection regime (NDPA, 2023).
• An OBCMS migration note: which scopes map to which surfaces once Bankit's OB enrollment is operationally live, so the swap is mechanical.

How the auth handshake reads in code

Illustrative — exact route names, header set and field names are confirmed during the build against the live channel. The shape is what a Nigerian-MFB mobile flow tends to look like: a phone-keyed initiate, an OTP confirm, a device-bound bearer, then reads. The NIP name-enquiry call before a transfer is non-optional in any Nigerian build.

import requests

S = requests.Session()
S.headers.update({
    "x-bankit-client": "android/3.x",   # mirror the released build
    "x-device-id":    DEVICE_ID,        # device-bound session
})

# 1. Initiate + OTP confirm
S.post(f"{BASE}/auth/initiate", json={"phone": PHONE})
tok = S.post(f"{BASE}/auth/confirm", json={
    "phone": PHONE, "pin": PIN, "otp": OTP,
}).json()["access_token"]
S.headers["authorization"] = f"Bearer {tok}"

# 2. Account snapshot + NUBAN
me      = S.get(f"{BASE}/accounts/me").json()
nuban   = me["primary_account"]["nuban"]
balance = me["primary_account"]["available_balance"]

# 3. Statement window
tx = S.get(f"{BASE}/transactions", params={
    "account": nuban, "from": "2026-01-01", "to": "2026-03-31",
}).json()

# 4. Outbound: NIBSS name enquiry, then transfer
ne = S.post(f"{BASE}/nip/name-enquiry", json={
    "destination_bank":    "044",          # bank code per NIBSS directory
    "destination_account": "0123456789",
}).json()
assert ne["account_name"], "name enquiry failed; do not proceed"

# 5. Bill payment (electricity biller as example)
bp = S.post(f"{BASE}/bills/pay", json={
    "biller_code": "AEDC", "customer_ref": "1234567890",
    "amount": 5000.00, "channel": "wallet",
}).json()

Errors return as a stable code plus a human reason; we map them to OB-standard error semantics in the delivered client so a later swap to OBCMS does not change the consumer of the library.

Things we plan around in a Bankit build

MFB sort code normalization. Nigeria's NIBSS bank-code directory issues longer codes to microfinance-bank participants than to the three-digit commercial banks. We normalize Bankit's CBN-issued code into the shared schema and verify it live against the NIBSS directory at the start of the build so outbound transfers and name-enquiry calls land on the correct counterparty without ambiguity.

Device-bound session lifecycle. The app advertises biometric login and real-time alerts, which in practice means a device-fingerprinted session token with its own refresh cadence. We design the integration around the device-registration step, run the refresh under the same fingerprint, and surface re-auth as a clear, signalled event so a downstream worker is not silently logged out mid-sync.

Web portal as a second source. Bankit's web banking platform mirrors the mobile ledger but uses a different session model. We treat it as a fallback channel for read paths during the build and as the secondary signal for the re-validation suite — if a mobile route shifts after a release, the same posting reconciled against the web portal flags the drift before any customer notices.

OBCMS-ready consent layer. We model the consent record from the first commit to match the CBN OB scope vocabulary (biodata, account details, transaction history, debit mandate). On the day Bankit's OB enrollment lights up, the consumer-facing consent UI does not change; only the wire underneath does.

NDPA data minimisation. Storage is scoped to the agreed schema; raw payloads are not retained beyond the audit window the customer chooses; BVN-linked identifiers are tokenised in the delivered client so the customer's own systems do not become an over-broad PII store.

What a Bankit integration is usually built for

• A Nigerian SME finance tool pulling balance and statement from a Bankit business account into its bookkeeping ledger nightly, with NIP-tagged counterparties matched to the SME's vendor master.
• A credit underwriter ingesting six months of statement and bill-payment cadence for a thin-file applicant whose primary account sits at an MFB rather than a tier-1 bank.
• A treasurer running a single consented sweep to reconcile cashback events and savings-goal movements against the in-house ledger at month end.

Other Nigerian apps in the same integration footprint

Where a Bankit integration is being designed as part of a wider Nigerian-fintech consolidation, these are the apps an integrator most often has to handle alongside it. Names are listed in plain text for reference; we do not rank or compare them.

• PalmPay — payments and savings app with a wide agent footprint; integration usually focuses on wallet balance, transfer history and bill payments.
• OPay — multi-product wallet (transfers, bills, POS for agents); the read surface looks similar to Bankit but with a richer merchant ledger.
• Kuda — digital bank account with savings and overdraft; statement and transfer history are the usual integration targets.
• Moniepoint — agency-banking and small-business banking; POS and merchant settlement data is the differentiator.
• Paga — mobile money with bill payments and remittance; integration tends to centre on transaction history and biller catalogues.
• Carbon — consumer credit and wallet; loan ledger and repayment history sit alongside the usual statement view.
• FairMoney — neobank and consumer-credit app; statement, loan schedule and card data show up together.
• ALAT by Wema — commercial-bank digital app rather than an MFB; useful when an integration spans both bank tiers.
• PiggyVest — savings and investment app; the integration target is goal balances and contribution history rather than transactional flow.
• Cowrywise — savings and mutual-fund investing; holdings and NAV history rather than current-account postings.

Questions we get on Bankit specifically

Does Bankit publish under a single NIBSS bank code we can hit by NUBAN?

Yes, but at the longer microfinance-bank code length used by Nigeria's MFB tier rather than the three-digit commercial-bank one. We verify Bankit's live code against the NIBSS bank-code directory at the start of the build and normalize it in the shared schema so name enquiry and outbound transfer reconcile against the central register.

Can a consent issued through CBN OBCMS already cover Bankit accounts today?

The CBN approved the open-banking framework's go-live for August 2025 and the operational rollout is phasing in through 2026; whether a given Bankit account is reachable through OBCMS at the moment depends on Bankit's enrollment status in the Open Banking Registry. We confirm that status at engagement start and route the build through OBCMS where it is live, and through authorized interface integration otherwise.

Is the data we pull NIBSS data or Bankit data?

Both, separated cleanly. Identity, balance, statement and card metadata live in Bankit's own backend. Outbound transfers, name enquiry and instant settlement run on NIBSS NIP rails that Bankit fronts. The delivered schema surfaces both behind one client but tags the source so downstream reconciliation can split them again.

How is the consumer's consent recorded if we're not going through OBCMS yet?

Written scope under NDA, the consumer's explicit per-session consent captured against their phone number and device, and a per-request audit log kept for the life of the integration. The same consent records carry forward when the workload moves to OBCMS so the customer does not have to re-paper the consumer.

Where we checked

Researched on 2026-05-30 against the bank's own materials and Nigerian regulatory and press sources. Primary citations:

• CBN Operational Guidelines for Open Banking in Nigeria (2023)
• TechCabal — CBN approves open-banking launch for August 2025
• NIBSS — Instant Payment (NIP) service
• Bankit: Send Money & Pay Bills — Play Store listing

Reviewed 2026-05-30 by the OpenBanking Studio integration desk.

Send the app name and what you need from its data to our contact page and we'll come back with a scope. Source-code delivery starts at $300, paid only after the integration runs the customer's first request end-to-end; the same surface is also operable as a pay-per-call hosted API, so the customer can call our endpoints and settle on calls without an upfront fee. A Bankit build typically closes in one to two weeks.

Notes last refreshed 2026-05-30.