FinToken X — Architecture

1. The problem in one paragraph

A small UK business sends a £10,000 invoice to a corporate customer. The customer will pay — in 60 days. The seller needs cash this week. Today the options are slow, expensive, and relationship-based. Meanwhile, pension funds and asset managers would happily lend against that invoice if only they could see the receivable in a standard format and trust the checks behind it.

FinToken X is the bridge. We verify the invoice is genuine, run identity and Anti-Money Laundering (AML) checks on every counterparty, and tokenise the confirmed receivable as an Ethereum Request for Comments 3643 (ERC-3643) security token on a permissioned chain. A regulated lender funds the token; the seller gets the cash. Investors then buy and sell slices on a permissioned secondary market, with a pre-trade compliance check on every trade. Every step is auditable, and every action by every actor is recorded in a tamper-evident log we can hand to the regulator on demand.

2. Who uses the platform

Eight personas. Five customers, three staff. Click any card for the persona's full flow.

Customers (pass the gates)

Staff (Role-Based Access Control (RBAC), no customer gates)

3. The four gates

Every customer passes through four checks before they can move money. Three are blocking; one runs continuously and raises alerts without stopping anyone up-front.

4. Who can do what

"Gates 1–3" means the actor must have cleared all three blocking customer gates before they may take the action. Staff bypass is RBAC-driven and audit-marked.

"Score API" is the Application Programming Interface (API) the broker uses for prequalification.

5. Money-control rules

Twelve invariants that govern what each persona is allowed to see and do. Violating any of these in a screen is a compliance defect, not a UX choice.

1. Seller's bank account is never rendered to the buyer or to the lender. Lender disburses to a FinToken-X-issued bankable virtual account; buyer pays the obligor instruction, which routes to FinToken X collections.
2. Buyer's bank account is never rendered to the seller. Buyer pays the channel FinToken X provides; seller never sees buyer's banking details.
3. FinToken X transit / settlement wallet is never rendered to the seller. Seller sees their own bank; money "just lands" with a FinToken X reference.
4. Internal IDs (subject IDs, audit IDs, contract addresses, tokenIds) are never rendered to anyone except platform admin and (optionally) the lender's API consumer. Customer-facing screens use the canonical invoice reference (FX-INV-23A4F) and human-readable bank details.
5. Funding is manual. No countdown, no auto-execute. The lender explicitly approves every receivable in step F2 → F3.
6. Platform fee is shown only to the seller in their settlement breakdown. Never on lender, investor, or buyer screens.
7. Discount rate / discount income is shown to the lender, investor, and (in summary form) the platform admin. Never to the seller (they see net cash) or to the buyer (none of their business).
8. Buyer confirmation is a hard gate. No funding screen, no token mint, no investor visibility until C2 confirmation lands.
9. Repayment is gated on inbound credit notification from the obligor's bank with a matching invoice reference. A buyer email saying "we paid" is never sufficient on its own.
10. Tokenisation happens server-side, post-confirmation, post-risk-clear. Token reference is shown to the lender, investor, and admin. Seller sees plain English — never 0x… addresses, never tokenId=….
11. Settlement currency is Great British Pound (GBP) fiat by default. Stablecoin (USD Coin, USDC) settlement is opt-in per lender, gated by Chainalysis wallet screening. Mixed currency is never offered to the seller.
12. Audit log marks every actor. When a platform admin acts on behalf of a customer, the entry is tagged actor_role=platform_admin, on_behalf_of=<subject_id> — non-negotiable for the regulator-facing audit trail.

6. Unit economics

What the platform charges and what each transaction costs to run. The rates below are the canonical values the billing, settlement, and partner modules apply; every figure on a screen anywhere in the doc set derives from this table. Money-control rules (§5) still govern who sees which figure.

Primary market — platform fees

Primary market — cost-of-goods per invoice

Operational cost per invoice processed. Inputs to the platform's gross margin model; not shown on any customer-facing screen.

Secondary market — trading fees

Secondary market — cost-of-goods per trade

Volume model parameters

The assumptions the platform sizes capacity, rate limits, and per-lender concentration caps against. Editable per partner deployment; surfaces on /admin/config.

Reconciliation with the canonical example invoice

Out of scope on this page

• Value Added Tax (VAT) treatment. Figures above are pre-VAT; the billing module computes VAT at invoicing time per UK tax rules.
• Discount rate / lender discount income — that is the lender's earning, not a platform fee. See lender flow for how discount rate is set, disclosed, and paid out.
• Commission paid to brokers — covered on the broker flow (broker.html) under commissions.

7. Token mechanics

FinToken X uses Ethereum Request for Comments 3643 (ERC-3643) tokens — also known as Token for Regulated EXchanges (T-REX) — on the permissioned FinToken X Network. Each confirmed invoice mints exactly one receivable token, divisible into slices for the secondary market, and burned on settlement.

Lifecycle states

8. Named entities

Canonical placeholder names used across every persona file. Don't introduce new named entities — use these. They are deliberately UK-flavoured and unambiguous.

Canonical example invoice

9. Regulatory framing

FinToken X operates under live and proposed UK rules. The doc set treats these as load-bearing constraints, not marketing flourishes.

10. Document conventions

• Step tags. Each screen has a tag like S3 (seller step 3), FCA SYSC 6.3 (regulator anchor), Gate 2, or INVOICE_TOKENISED (state-machine event). State chips never appear inside browser screens or email bodies — only in commentary cards.
• Pills. Status pills follow a fixed palette: Settled Listed Past due Default Tokenised.
• Commentary cards. Blue-bordered boxes with engineering-side notes on state, Service-Level Agreement (SLA), error branches. Aimed at the doc reader, not at the persona on screen.
• The flow strip. Each persona's screen-by-screen flow lives in a horizontal scrollable strip. Free-scroll, no snap.
• Routes. Every browser-frame URL bar shows the actual route from src/App.tsx. If a route is annotated as "new — needs implementation", that means the spec calls for it but the codebase doesn't have it yet.

11. Glossary of abbreviations

Every short form used across the architecture, spelled out. Pages spell each term out in full on first use; this table is the canonical reference for everything that follows.

12. Where to read next

• If you want to understand how a single invoice flows from submission to settlement across all personas — read end-to-end view.
• If you want services, data model, integrations, and full state machines — read backend & data.
• Otherwise pick the persona whose journey you care about from the cards above.