Terracore Financing Bot — UI Flow

Hard rules — every screen and every email must comply

• Supplier bank account is never rendered to the buyer. Not in the payment-instruction email, not in the reminder, not in the receipt, not anywhere. Only the financier's dedicated repayment account appears.
• The Terracore transit wallet of the supplier is never rendered on a supplier-facing screen. The supplier sees only their own settlement bank account. The financier sees the wallet (it is what they fund — see next rule), but never the supplier's bank account. Terracore handles the wallet → bank transfer automatically, deducting the platform fee at the wallet level.
• The financier's view of the rail is a single transaction with Terracore — they pay us, we pay them back at maturity. They never see the supplier's bank, never see how funds flow on the backend, never see Terracore's internal wallet IDs or virtual-account routing, never see the platform fee, and never see what the supplier actually receives in their bank. From the financier's perspective: "I funded this invoice; I get repaid in 30 days." Settlement on the supplier side is fully Terracore's responsibility, on the backend, invisible to the financier. This protects the supplier's banking relationships and structurally prevents the financier from bypassing Terracore.
• Funding is manual — there is no auto-execute, no countdown, no default disbursement. Each invoice waits for the financier's explicit "Approve & fund" tap, which arrives only after Bokku procurement confirms delivery (BRD §5; financier sees the procurement-confirmation email directly because they are Cc'd). The financier may decline at any time before approval; no money has been moved.
• Terracore's platform fee is disclosed only to the supplier — the party paying it. The fee appears as a line item in the supplier's terms screen (S4) before they accept, and the post-fee net is shown in the supplier's funded receipt (S6). The fee is never shown to the financier — it is between Terracore and the supplier and has nothing to do with the financier's funding decision.
• The buyer's payment instruction is delivered by email to their finance department (finance@ / accounts@ / ap@ alias on the buyer's domain) — not WhatsApp, not SMS. The financing partner is on every email as Cc:, and an internal Terracore audit alias is on every email as Bcc:. WhatsApp is never used for any buyer-facing money instruction.
• Every email that contains payment details is signed — SPF, DKIM, and DMARC pass on terracore.ng. The buyer's email client renders the verification badge automatically. We never send payment instructions from an unverified domain.
• Every buyer payment instruction includes a unique reference (TC-INV-{id}-{checksum}) — narration that the financier's bank webhook (or reconciliation file) uses to map the inbound payment to the right invoice in the Terracore ledger. No reference, no auto-reconciliation. The reference is repeated three times in the email (subject, bank-details card, warning block).
• Document authenticity is verified at submission, not later (BRD §3 & §6). The submitted document varies by supplier industry: General Trade suppliers submit a stamped invoice (+ optional PO); Agro suppliers submit a validated weighbridge ticket or Goods-Received Note. Every document — whichever variant — must pass vision-extracted authenticity checks before it enters the state machine: buyer's stamp present, buyer's signature present, extracted economic terms (line items + total for invoices; weight × grade-priced total for tickets), and internal-consistency reconciliation. Any check fails → reject and ask for re-upload. We do not advance on AI confidence alone — the supplier must also confirm in chat. Industry is set on the supplier profile at signup; S2 branches accordingly.
• Buyer's delivery confirmation is a hard gate (BRD §5) — routed to the team configured on the buyer profile. Larger buyers route Phase-1 confirmation to a dedicated procurement / receiving alias (procurement@, ops@, warehouse@); smaller buyers where finance handles operations route it to finance@ directly. We capture this on the buyer profile at first-invoice setup. Either way the same two channels run in parallel: (1) email to the configured alias with the named contact and financing partner Cc'd (formal record), and (2) a WhatsApp nudge to the named contact for speed. Confirmation can come back via either channel; the OTP that proves identity always goes to the contact's verified corporate email on the buyer's domain — never to a personal address. Phase 2 (payment instruction to finance) only fires after this gate passes.
• Terracore does not custody repayment funds. The buyer pays directly into the financier's own dedicated bank account — provisioned by the financier (typically a microfinance bank with their own banking infrastructure) for Terracore-routed payments. Funds never touch Terracore. Our system records each transaction in the financier's read-only Terracore ledger for reconciliation and reporting — like an accounting view, not a custodial wallet. (Matches BRD Notes §5: "Repayment does not return to platform first; platform acts as routing + orchestration layer.")
• Repayment confirmations are never sent on buyer reply alone. The "buyer paid" receipt email — and the parallel WhatsApp confirmations to supplier and financier — render only after we receive the inbound-credit notification from the financier's bank (webhook or reconciliation file) with a matching reference.
• Every WhatsApp template that contains money detail carries a verification badge (the green tick on the bot avatar) so users can distinguish it from impersonation attempts.
• Internal admin metrics are never rendered on customer-facing screens. Credit standing, available headroom, exposure used, financier limits, performance scores, risk grades, and any other underwriting / risk-management metric — these belong on the dashboard, owned by the financing partner and Terracore ops. Suppliers and buyers see only what concerns their own role: invoice status, payment events, and next actions. No leakage of internal portfolio data into chat bubbles or emails.