1. Treasury Flow — IBAN → IBAN Settlement
This is the only place where real money moves. It must be treated strictly as institutional funding.
IC CC (SPI)
Safeguarding Ledger
SEPA / SWIFT · IBAN → IBAN
▼
BNK2 (VASP)
Treasury IBAN (Jeton)
▼
[ TREASURY POOL ]
Bank view
Sender: IC CC Ltd
Receiver: BNK2 Ltd
Purpose: Treasury Funding
Key rules
- Rail: SEPA / SWIFT only
- Beneficiary: BNK2 (legal entity)
- No FBO
- No User references
- Classified as treasury / prefunding
Controls required
- KYB on BNK2
- Sanctions screening
- Safeguarding reconciliation
- Contractual agreement
2. Internal Allocation Flow — Off-Bank
No real money moves here. This is purely ledger movement inside BNK2.
Treasury Pool
BNK2
API instruction · (user_id, amount)
▼
BNK2 Ledger
Debit: Treasury Pool
Credit: User Account
Credit: User Account
▼
USER WALLET
No bank rails. Responsibility: BNK2 = full control + compliance.
Key rules
- Driven by API instruction
- BNK2 responsible for AML / KYC
- Allocation must match prefunded balance
- Full audit trail required
3. End-to-End Flow — Full Stack
Complete lifecycle. Separation between bank layer and ledger layer is critical.
User (SPI)
▼
IC CC Ledger
SEPA / SWIFT
▼
BNK2 IBAN
Treasury
▼
Treasury Pool
API / Internal
▼
BNK2 Users
Critical boundary
▲ BANK LAYER SEPA / SWIFT, regulated rails, KYB beneficiary
▼ LEDGER LAYER API instructions, internal accounting, KYC on users
Do not mix the two. The bank-rail leg sees only legal entities. The ledger leg sees users.
4. Non-Compliant Patterns — Do Not Do
The following break compliance and trigger AML flags, layering suspicion, and audit failure.
Patterns that break compliance
- Using FBO in a treasury transfer
- Embedding user references in an IBAN payment
- Treating an IBAN transfer as a user payout
- Mixing the treasury and allocation layers
- Not reconciling balances
What these trigger
- AML AML flags
- Risk Layering suspicion
- Audit Audit failure