Demonstration environment — simulated data

Architecture

How the platform is built, and what changes on the path to production

1

Channels

WhatsAppSMSEmailIn-app chatPushVoiceBranch portal

Where the customer actually is. Nothing here is a new banking app the customer has to be persuaded to install.

2

Experience layer

Command CenterLoan lifecycleDocument intelligenceMessaging hubTrade financeCompliance console

Role-aware interfaces. Six personas see six different versions of the same underlying data.

3

AI orchestration

Intent routerTool registryExecution traceApproval gateExplainability engineAudit writer

The layer that makes it an agent rather than a chat window: it selects tools, records what it touched, and stops at the human gate.

4

Model layer

Reasoning LLMPolicy embeddingsDocument classify + extractSME risk modelAnomaly detectionTrade document checker

All bank-resident. No public internet egress, no customer data leaving the perimeter.

5

Integration layer

CoreBankingAdapterMessagingAdapterDocumentAdapterXapis API managerEvent busRetry and dead-letter

One interface per capability. The vendor behind it is a configuration detail, which is what makes the platform portable.

6

Core banking

Temenos T24Oracle FLEXCUBEFuteric Core Banking

Unchanged. The platform reads and writes through the adapter and replaces nothing the bank already runs.

End-to-end data flow

  1. 1Customer sends a document over WhatsApp
  2. 2Messaging adapter normalises and stores it
  3. 3Document AI classifies and extracts fields with confidence
  4. 4Low-confidence fields route to a human queue
  5. 5Risk model re-scores using the new evidence
  6. 6Explainability engine attaches factors to sources
  7. 7Analyst reviews; approver records the decision
  8. 8Adapter writes the loan record to core banking
  9. 9Notification goes back out on the customer's channel
  10. 10Every step above writes one audit row

What is simulated in this demo

  • All customer, application and document data — fictional
  • Core banking responses — generated locally by mock adapters
  • Message delivery states — no channel provider is contacted
  • Model inference — deterministic routing, not a live model call
  • Policy documents — written for this demo, not regulatory text

Adapters implemented

  • Temenos T24T24AdapterSimulated
  • Oracle FLEXCUBEFlexcubeAdapterSimulated
  • Futeric Core BankingFutericCoreAdapterSimulated

The path to production

What stays as built

  • Domain model and types
  • Experience layer and RBAC
  • Orchestration logic and approval gates
  • Execution trace and audit writer
  • Design system and bilingual support

What gets replaced

  • Mock adapters with production adapters
  • Seed data with real datastores
  • Deterministic routing with real model inference
  • Local policy file with a vector store
  • In-memory state with a persistence layer

What must be added

  • Authentication and enterprise identity federation
  • Encryption in transit and at rest
  • Monitoring, alerting and tracing
  • Model versioning and rollback
  • Penetration testing and security review