The system architecture was deployed across three key operational pillars inside a unified administration network — each enforcing a distinct layer of the FCA's AML and CTF requirements.
To satisfy the FCA's stringent anti-money laundering (AML) and counter-terrorist financing (CTF) requirements, Touch-Fire implemented a rigorous automated verification state machine for both personal and corporate applications.
[ User Submits KYC ]
|
v
[ Status 1: Pending Admin Approval ] ---> Admin verifies Main ID & Selfies
|
v
[ Status 2: Pending External KYC ] ---> API call to NorthRow Oracle
|
v
[ Status 3: Pending Admin Approval 2 ] --> Evaluates NorthRow Score
|
+-----+-----+
| |
v v
[ 4: Approved ] [ 5: Rejected ]
Personal Accounts Workflow: The automated onboarding engine routes new requests into a preliminary administrative queue. Internal operators use specialised visual validation interfaces to match official document attachments — Passports, Residence Permits — alongside selfies and proof-of-address documents.
External Oracle Integration: Once baseline checks pass, the platform automatically initiates an API-driven verification loop with NorthRow, an institutional compliance oracle. The system transitions the user status through a controlled pipeline and returns an algorithmic verification score (e.g., Score: 1001) with colour-coded indicators (Green, Amber, Red) for final operator confirmation.
Granular Rejection Defensibility: In compliance with regulatory auditing requirements, the platform uses a structured exception handler that forces administrators to log a precise rejection reason — such as "Invalid Address" or "Different Address indicated on Supporting ID and Proof of Address" — before a rejection status can be committed. This creates an unambiguous, auditable paper trail for every declined application.
A core component for preventing unauthorised capital flight is the Automated Whitelist History and Control Engine. This layer ensures that all digital asset payouts are executed exclusively to pre-audited nodes on the blockchain network.
Cryptographic Identity Binding: When an administrator reviews a whitelisting request, the interface dynamically checks underlying database records to ensure the destination public key address — Bitcoin (BTC), Ethereum (ETH), or other supported networks — is tied securely to a verified customer identity record.
State-Driven Address Lifecycle: Digital asset wallet addresses are tracked through a fully audited lifecycle:
Approved
→
Amended
→
Removed
If an address is removed, it is systematically deprecated and permanently flagged with historical timestamps inside the compliance ledger — ensuring that no removed address can ever be silently reactivated or recycled for a fraudulent payout.
The withdrawal framework functions as a secure bridge between internal ledger accounting, multi-signature custodian authorisation, and external public blockchain integration — progressing through eight discrete states to prevent double-spending and out-of-sync ledger conditions under high-volume transaction loads.
[ User Requests Withdrawal ]
|
v
[ Status 1 & 3: Pending Approval ] ---> Automated Whitelist Check (PASS / FAIL)
|
v
[ Status 4: Approved ] ---> Custodian Reviews & Confirms Transaction
|
v
[ Status 6: Initiated ] ---> Broadcast to Blockchain Node
|
v
[ Status 8: Completed ] ---> On-chain block consensus confirmed
Automated Whitelist Verification: The moment an asset withdrawal is generated, the gateway executes an immediate internal check against the Whitelist engine. If the destination node fails verification, the transaction is systematically blocked and flagged before any custodian interaction occurs.
Fail-Safe Node Exception Handling: If an infrastructure or consensus error occurs during transmission to the blockchain layer, the gateway instantly isolates the asset pool, registers a Node Error or Error Unbound status, and pauses the ledger to prevent downstream discrepancies — ensuring no transaction is ever left in an ambiguous state.