Persona-specific entry

This screen is the financier branch of the cross-persona picker (Supplier flow O1). Self-service Flow registration replaces the previous white-glove handoff because Financing Partners — typically MFB ops or treasury staff — expect to capture compliance data themselves.

What we name up front

The required documents (CAC, designated account, contact details) are listed in the bubble before the Flow opens. Pilots showed in-Flow abandonment dropped sharply when the document list is named pre-Flow.

Speed budget ≤ 600ms

Pre-rendered persona-variant template. Tap → next screen renders inside ~200ms.

Why each field is captured

• Registered business name + CAC RC: validates the legal entity. CAC API call returns business status, MFB licence, registered name; mismatches block the Flow.
• Authorised representative: the named individual who acts on the institution's behalf — receives all WhatsApp alerts, ledger access tokens, and is the audit-trail signatory.
• Designated settlement account: the bank account where all obligor remittances on this Financing Partner's discounted receivables will be credited. This account is disclosed in the BRD §9 obligor payment instruction email — it must be the institution's own account at their preferred bank, not a personal account. NIBSS NameEnquiry confirms the account name matches the CAC-registered name.
• Concentration limits: total exposure cap, maximum outstanding, maximum per receivable. Enforced server-side; F2 receivable-discount notifications won't render for receivables exceeding these limits.

Live verifications

CAC RC blur → CAC public API; NIBSS NameEnquiry on account number blur with fuzzy match against CAC-registered name. Both must succeed before the "Register institution" CTA enables.

What this submission produces

One signed JSON payload — institution metadata, authorised representative, settlement account (verified), limits, T&C version, timestamp, device fingerprint. This is the Master Receivables Financing Agreement consent record.

Speed budget ≤ 1.5s per real-time verification

Terracore does NOT custody Financing Partner funds

The Financing Partner provisions a designated settlement account at their own bank and registers it on Terracore. All obligor remittances against receivables they discount land directly in that account. Our system records each posting in the Financing Partner's read-only Terracore ledger — a reconciliation and reporting view, not a custodial wallet. Matches BRD Notes §5: "Repayment does not return to platform first; platform acts as routing + orchestration layer."

The designated settlement account is rendered to obligors

This is the same account the obligor (e.g. Bokku) sees on the BRD §9 payment instruction email — disclosed transparently to the buyer's finance team, with Terracore as the From-address and the Financing Partner Cc'd. The Financing Partner's account becomes the obligor-facing remittance destination.

Why bot, not dashboard, for first-touch

Financing Partner ops staff are mobile during the day. They are notified on WhatsApp; deep ledger work happens on dashboard. The bot is the alert plane.

Concentration limits are echoed back

Showing the limits the Financing Partner set in the Flow right back to them on WhatsApp closes the trust loop — they confirm we have the correct numbers.

Disbursement is discretionary — no auto-execute

This screen has no countdown, no automatic disbursement. The Financing Partner explicitly approves each receivable. The notification arrives only after the obligor's procurement team has confirmed delivery (BRD §5) — the Financing Partner saw that confirmation directly because they were Cc'd on the procurement email.

Vocabulary

Standard receivables-financing terminology throughout: Originator (party selling the receivable — the supplier), Obligor (party owing payment — the buyer), Face value (gross invoice amount), Discount rate & Discount income (Financing Partner's earning), Net advance (cash to disburse), Tenor, Maturity date.

What the Financing Partner sees here, and what they do not

They see the receivable's economic terms, the obligor's credit profile, the risk score, and the delivery-confirmation timestamp. They do not see the originator's bank details — that is private to Terracore. The next screen (F3) shows them the Terracore-managed account to remit the advance to.

Three buttons, deliberately

Approve & disburse → opens F3 with the account to remit. Review in ledger → deep-dive: invoice PDF, waybill, originator history, ageing on similar receivables. Decline → freezes the receivable and notifies the originator's account manager (no funds move, no penalty).

Speed budget ≤ 5s for this screen to render

From DELIVERY_CONFIRMED to F2 landing in the Financing Partner's WhatsApp. The Financing Partner's own decision time is unbounded — that's their underwriting judgement.

What the financier sees on this screen — and only this

A bank, an account number, an account name, a narration reference, and an amount. Nothing else. From the financier's view this is a single transaction with Terracore — they pay us, and we pay them back at maturity. They never need to know what happens behind that account.

What we deliberately do NOT show the financier

• That the account is "virtual" or backed by a wallet. Internal architecture. To them it's just a regular bank account.
• The supplier's bank account. Hidden by design — the financier should not have the data needed to bypass Terracore.
• Terracore's platform fee. The fee is between Terracore and the supplier — none of the financier's business.
• The supplier's net receipt amount. Same reason. The financier funds ₦4,410,000; what the supplier ultimately gets in their bank is internal settlement.
• Wallet IDs / internal identifiers. Terracore bookkeeping.

Backend reality (engineering reference, not shown to user)

The account number rendered is a virtual NUBAN issued by our partner bank (Wema / Providus), reserved per supplier + invoice and resolving to a SUPPLIER_TRANSIT wallet on our books. Inbound credit triggers: (1) Terracore deducts the platform fee (~1% of invoice, configurable per supplier's commercial terms); (2) the net is remitted to the supplier's actual settlement bank via NIBSS instant. None of this is visible on the financier's WhatsApp.

Financier pays from their own bank — Terracore does not custody capital

The financier (a microfinance bank) holds capital in their own treasury / bank infrastructure. They tap "Copy account number", paste it into their own bank or treasury system, and make a normal NIBSS-instant transfer with the reference in narration. Terracore's virtual account receives the inbound credit, deducts the platform fee on the backend, and remits the net to the supplier's settlement bank. None of those steps are visible to the financier.

Money-control assertion

The account rendered here is asserted in code: it must resolve to a SUPPLIER_TRANSIT wallet, scoped to this invoice, owned by Terracore, beneficiary = the supplier. The renderer refuses to send if it isn't.

Speed budget ≤ 600ms after F2 approval tap

Single-purpose receipt — no buttons

The financier already made the decision in F2 and paid in F3. This is acknowledgement and forward-looking detail (when they'll be repaid, what they'll earn). No decision point.

What the financier sees and what they don't

They see: confirmation we received their funds, the repayment schedule, and their exposure. They do not see — at any point — Terracore's platform fee, the onward leg, the supplier's actual bank, or the net amount the supplier receives. Settlement on the supplier side is entirely on Terracore's backend; from the financier's view, this was a single transaction with us.

Backend reality (engineering reference, not shown to user)

On inbound credit to the supplier's virtual account, Terracore deducts the configured platform fee and remits the net to the supplier's settlement bank via NIBSS instant. The supplier's WhatsApp S6 fires with their post-fee net amount. None of this state is reflected in the financier's chat.

Exposure and earnings surfaced inline

Running exposure plus expected return for this deal are rendered with every funding receipt so the financier never has to ask "How much am I out?" or "What's my P&L?".

Funds went directly to the financier's bank — Terracore did not custody anything

Bokku transferred ₦4,500,000 directly into the financier's dedicated Wema Bank account. Terracore is notified of the inbound credit (via the financier's bank webhook or reconciliation file) and records the transaction in the financier's read-only Terracore ledger. Terracore never touched the funds.

Reference-match line is mandatory

The "Reference matched ✓" line is the financier's structural assurance that funds were applied to the right invoice. If a buyer pays without reference, this message is replaced with "Unmatched payment — review" and routes to ops.

Performance YTD

Running performance numbers turn every repayment into a small status report — the financier never has to log into the dashboard to feel confident.

Suspension is automatic — no acknowledgement required

At 85% utilisation, Terracore stops sending new-receivable notifications until exposure drops or the cap is raised. This happens the moment the threshold trips. The Financing Partner does not need to confirm or "accept" the suspension — doing nothing keeps it in force. Two actions exist if they want to change something: raise the cap, or review outstanding receivables in the ledger.

Why we never silently exceed a cap

Concentration limits are an underwriting control, not a soft target. Crossing them without explicit Financing Partner action would be a regulatory and audit problem for an MFB. Suspension is automatic and stays in force until the Financing Partner explicitly raises the cap in the dashboard or scheduled settlements free up headroom.

What "Review outstanding ledger" does

Routes to the dashboard's Receivables register, pre-filtered to Outstanding. The Financing Partner can see exactly which receivables are consuming their exposure, what's maturing this week (settlements that will free up headroom), and decide whether to wait for natural amortisation or raise the cap.