Reaching Iustus loan records under Nigerian consent rules

₦5,000 to ₦100,000 over 91 to 180 days, with a 10% processing fee taken at disbursement — that is the product surface Berly Spring Global ships under the Iustus brand on Google Play. A single naira loan moves through application, KYC, disbursement, repayment, and either payoff or rollover, all on a server Berly Spring controls behind a session the borrower holds in their phone. None of that record lives on the device for long. The integration question is therefore not "where is the data file" but "whose consent reaches the server, and through which authorized channel".

The short answer for an Iustus integration is the borrower's own consent: the loan record, the repayment schedule, and the derived credit signal sit behind their authenticated session and come out cleanly when they grant access. The bank-side cashflow — the disbursement landing in their account, the repayment debit leaving it — is the leg where Nigeria's Open Banking framework will eventually slot in. We build the integration so both legs join up in one normalized record on your side.

What sits behind a borrower's Iustus session

Field names below follow what the Play Store listing and the in-app screens use; granularity is what an integrator would actually receive, not what the operator stores internally.

Authorized routes

Three routes apply here. They are not mutually exclusive — the build we usually ship for a Nigerian lender combines two.

1. User-consented integration of the Iustus session

The borrower authorizes us to reach their authenticated Iustus session, and the integration mirrors the screens they already see: active loan, repayment schedule, history, credit-tier. This is the spine of the build because it is the only route that returns the lender-side record. Effort is moderate; durability depends on how often Berly Spring revises the mobile client. We arrange the authorization paperwork with you during onboarding so the consent record matches what NDPA asks for.

2. Nigeria Open Banking on the bank-account leg

The CBN issued Africa's first open-banking regulatory framework in February 2021 and finalized the Operational Guidelines in March 2023, with a phased rollout through 2026 operated by NIBSS via the Open Banking Registry and the Open Banking Consent Management System. That framework reaches a borrower's bank account — where the Iustus disbursement lands and where each repayment is debited — once they consent. It does not cover Iustus itself, which is a consumer of the ecosystem rather than a provider. We design the bank-side leg so it switches from authorized portal access to the regulated AIS endpoint without a rewrite once NIBSS opens the registry to non-bank participants.

3. Native export, where the borrower can pull it

Where Iustus shows the borrower a statement or repayment list inside the app, we treat that as a sanity-check channel: the borrower exports what they can see, the integration reconciles it against what came through route 1. It is not a primary route — it is how we prove the integration's numbers match what the borrower would read with their own eyes.

For most Iustus engagements we lead with the user-consented session route and add the Open Banking leg on the bank-account side; the native-export channel stays a build-time reconciliation tool rather than a primary feed.

What lands in your repo when we finish

• An OpenAPI 3.1 specification covering the Iustus session endpoints we wired, including request and response schemas for active loan, repayment schedule, history, and the derived credit tier.
• A protocol and auth-flow report. For Iustus that means the session-token chain — login, refresh, and the device-binding header the client sends — written up against captured traffic from a consenting account.
• Runnable source in Python and Node.js for the endpoints listed in the OpenAPI doc, with a thin adapter layer so the same call site survives small portal changes.
• Automated tests against a recording of the consenting account's session, plus a re-record script so the test corpus refreshes itself on the next session.
• A normalized-record schema that joins the Iustus loan side with the Open Banking bank-side cashflow, so one record per loan carries both legs.
• An NDPA-aligned consent and retention note: scope of what the borrower agreed to share, expiry, revocation handler, and a data-minimization map showing which Iustus fields cross the wire and which stay on the device.
• A short interface document the recipient team can read in one sitting, not a wiki dump.

A request the integration would actually run

Illustrative — exact paths and headers are confirmed during the build against a consenting borrower's session, not asserted from afar.

# Fetch the borrower's active loan + repayment schedule, then
# pair it with the Open Banking debit that paid the last installment.

import httpx, datetime

IUSTUS_BASE = "https://api.iustus.example/v1"   # confirmed during build
OB_BASE     = "https://ais.bank.example/v3"     # CBN OB AIS endpoint, per consent

def active_loan(session_token: str, borrower_id: str) -> dict:
    r = httpx.get(
        f"{IUSTUS_BASE}/borrowers/{borrower_id}/loans/active",
        headers={
            "Authorization": f"Bearer {session_token}",
            "X-Device-Id":    "<bound at first install, replayed thereafter>",
            "Accept":         "application/json",
        },
        timeout=10.0,
    )
    if r.status_code == 401:
        # NDPA-aligned: refresh through the same consent record, do not re-prompt.
        raise SessionExpired(borrower_id)
    r.raise_for_status()
    return r.json()
    # { "loan_id": "...", "principal_ngn": 10000, "term_days": 91,
    #   "processing_fee_ngn": 1000, "interest_ngn": 350,
    #   "balance_ngn": 11350, "next_due": "2026-08-28", ... }

def reconcile_last_repayment(loan: dict, ob_token: str) -> dict:
    last_due = loan["repayments"][-1]
    txns = httpx.get(
        f"{OB_BASE}/accounts/me/transactions",
        params={"from": last_due["due_date"], "to": last_due["due_date"]},
        headers={"Authorization": f"Bearer {ob_token}"},
    ).json()
    match = next((t for t in txns["data"]
                  if t["counterparty"].lower().startswith("iustus")
                  and t["amount_ngn"] == last_due["amount_ngn"]), None)
    return {"due": last_due, "bank_match": match}

NDPA, FCCPC, CBN — the compliance footing

Three rule sets touch an Iustus integration, and they do different jobs.

The Nigeria Data Protection Act, 2023, which received Presidential assent on 13 June 2023 and is supervised by the Nigeria Data Protection Commission, is the consent rulebook. It requires consent that is freely given, specific, informed and unambiguous; it bans inferring consent from inactivity or pre-ticked boxes. The integration is built around a written consent record that can be produced on demand, with revocation handled in the same flow. Data minimization is taken literally here: the SMS-derived signals the Iustus client reads for its credit score are not relayed through the integration — only the derived tier or limit the borrower can see in-app is shared.

The Federal Competition and Consumer Protection Commission registers Iustus and the rest of the digital-lender category under the Limited Interim Regulatory Framework and Guidelines for Digital Lending 2022; Iustus appears on the FCCPC's approved digital money lenders list as referenced in publicly circulated 2026 updates. That registration is the operator's, not the integrator's, but it matters to scope: we treat the integration as touching a regulated digital lender and document that posture in the engagement record.

The CBN's Open Banking framework — issued February 2021, Operational Guidelines March 2023, phased through 2026 — covers the bank-side leg only. NIBSS operates the Open Banking Registry and the Consent Management System; consent is anchored to the BVN. We code the bank-side route so the access switch from authorized portal to regulated AIS endpoint is a configuration change, not a rebuild.

What we plan for during the build

• The SMS-derived credit-score line. The Iustus listing is explicit that SMS history feeds the credit score on first install. We scope the integration so that signal stays on the device: only the derived tier or limit the borrower already sees in-app is relayed. NDPA's minimization rule is the reason we draw the line there, and it is a line worth drawing on the page rather than the contract.
• Loan-life cadence rather than fixed polling. An Iustus loan lives 91 to 180 days. A nightly sync wastes calls for most of that lifecycle and still misses the moments that matter — disbursement landing, an installment going past-due, a payoff. We tie the sync cadence to events on the repayment schedule the integration itself reads, so the record stays fresh exactly when it has to.
• Mobile-client revisions. A digital lender's app evolves between releases — fields rename, an extra step lands in the login chain, a header gets bound differently. We carry a recorded session as part of the test corpus and re-record on each release so the regression catches a portal change the first time we look, not the third.
• Open Banking phasing. The bank-side leg is built behind an interface so the day NIBSS opens the registry to non-bank participants, the implementation switches from authorized portal access to the regulated AIS endpoint without the loan-side code knowing. We also model the BVN-anchored consent envelope that framework expects.

Integration scenarios we have shipped variants of

• Lender-side aggregator. A multi-lender repayment dashboard reading the same borrower's record across Iustus, FairMoney, Carbon and Branch, normalized into one outstanding-exposure view. Useful for collections triage and for the borrower's own debt overview.
• Underwriting reuse. A neobank or BNPL operator pulling closed-loan history out of Iustus, with the borrower's consent, to inform its own credit decision on a new product. Only the derived signals cross the wire; raw SMS data does not.
• Reconciliation between loan ledger and bank statement. Pairing the Iustus repayment schedule with the bank-account debit that paid each installment, so a mismatch — short pay, partial pay, retry charge — surfaces the day it happens rather than at month-end.

Pricing this engagement

An Iustus build is delivered for a flat USD 300 starting fee for the source-code package: the OpenAPI document, the runnable Python and Node.js code, the captured-session test corpus, and the interface report. You pay only once you have run the build against your own borrower-consent record and accepted it. The alternative is the hosted route — call our endpoint per query, pay only for what you call, no upfront engineering fee. Delivery cycle is one to two weeks from the kickoff call. To start, send the brief through the contact form; we reply with a scope note and an authorization template.

Sources we read before writing this

This page was put together from primary documents and the operator's own listing. The 2026-05-29 review covered:

• Iustus on Google Play — the product surface, fee structure, eligibility, and the SMS-consent line are taken from the operator's listing.
• CBN Operational Guidelines for Open Banking in Nigeria (March 2023) — the bank-side framework, NIBSS-operated registry and consent management.
• FCCPC, Registration of Digital Money Lenders — the regulatory regime under which Iustus operates as a registered digital lender.
• Nigeria Data Protection Act, 2023 — the consent and minimization standard the integration is engineered against.

Mapping reviewed 2026-05-29 by the OpenBanking Studio integration desk.

Other Nigerian lenders in the same shape

Iustus sits in a crowded category — over 430 digital lenders are currently approved by the FCCPC. The names below are operators whose data shape is similar enough that a single normalized record can carry them all.

• FairMoney — short-term personal loans and a payments side, with one of the largest borrower bases in the category.
• Branch — naira loans of 61–180 days, with a similar SMS-and-device credit-signal approach.
• Carbon — installment lending plus a wallet; closer in shape to Iustus on the repayment-schedule side.
• Renmoney — longer-tenor loans and higher ticket sizes, useful as the "upper end" comparison in a multi-lender view.
• OKash — Blue Ridge MFB-backed, salary-domiciliation-style underwriting.
• Aella Credit — loans up to ₦1,000,000 over 1–3 months; same broad data shape, larger ledger.
• Palmcredit — sub-₦100,000 short-term loans with a proprietary device-metadata score.
• QuickCheck — short-tenor personal credit; publishes its own analysis of the Nigerian lending market.
• PadiCredit — newer entrant in the small-ticket bracket.

Integrator questions we get about Iustus

Can we pull a borrower's outstanding Iustus balance without making them reinstall the app?

Yes, with their consent. The active-loan view is a server-side record on Berly Spring's backend, reached through the borrower's existing session token rather than the install. The integration is built to refresh that record on a cadence matched to the repayment schedule on file.

Where does Iustus actually store its credit-score signal, and is that signal portable to our underwriting?

The Play Store listing describes the score as derived from SMS history and repayment behavior; what surfaces in the app is a tier or a limit, not the raw signal. The integration delivers the derived fields the borrower can authorize sharing — limit, tier, last-update time — and never the underlying SMS payload, which is the line NDPA's data-minimization rule asks us to draw.

Does Nigeria Open Banking cover Iustus itself, or only the bank side of the cashflow?

The CBN framework, finalized in the March 2023 Operational Guidelines and on a phased 2026 rollout via NIBSS, governs licensed banks and PSPs as API providers. Iustus, a registered digital money lender, sits on the consumer side of that ecosystem rather than as a provider. So Open Banking reaches the borrower's bank account where disbursements land and repayments leave; the in-app Iustus ledger comes through user-consented integration of the Iustus session itself.

Is integrating an Iustus account under NDPA 2023 actually legal?

Yes when the data subject's consent is freely given, specific, informed and unambiguous — the standard the Nigeria Data Protection Act, 2023 sets out, and the same standard the NDPC enforces. The integration is designed around that consent record, with revocation handled in the same flow that captures it.