Solution architecture

A modern fund administration stack, built from the ground up.

SMART-TA is a microservices platform with a dual-layer data architecture, DLT-underpinned immutable state, embedded AI governance, and source code delivered under a commercial perpetual licence.

Platform layers

End-to-end architecture from portal to blockchain.

Each layer is independently deployable, horizontally scalable, and designed for regulated financial operations.

01 Digital channels Portal layer

Investor portal

Distributor portal

Operations portal

Compliance portal

02 BFF (Backend for Frontend) microservices: act as a protective layer and strategic buffer that supports performance and data formatting Experience layer

Customer journeys

Role-based views

Workflow actions

Experience APIs

03 Application services Core microservices

Core SMART-TA

InvestorsRegister management

FundsFund structures

ProductsWrapper rules

OrdersSub & redemption

HoldingsPosition management

NAVPricing & valuation

PaymentsSettlement flows

DistributionsIncome allocation

ReportingRegulatory & client

Corporate actionsEvents & elections

DeFi TA services

KYC claims

Wallet linking

Tokenised orders

NAV publication

Transfer validation

Event capture

SMART-Connect

SWIFT MT/MX

Clearstream & Euroclear

Calastone

Euroclear UK & International (EMX / CREST)

DTCC / NSCC

Canadian Fundserv

04 Platform services Cross-cutting infrastructure

Workflow engine

Deterministic orchestration · AI-generated advice · Escalation & SLA · Audit trail

GRC & AI governance

Embedded compliance · Three-layer attestation · DORA alignment · Risk scoring

Access management

Keycloak SSO/MFA · OPA policy engine · RBAC/ABAC · Zero-trust

Integration fabric

Legacy systems · Provider adapters · Certified connectors · Retry & audit · Event publishing

Private AI — no data leaves client environment

Local model deployment · Anomaly detection · Operational insight · Explainable outputs · Role-based intelligence

05 Dual-layer data architecture Immutability as infrastructure

Write path

Microservice → PostgreSQL → Domain Event Bus → DLT Commitment Service → CeFi Event Ledger

Operational layer (mutable)

PostgreSQL — OLTP

Microservice-owned schemas

ClickHouse — OLAP

Analytics & reporting

Domain
event bus

DLT
Commitment
Service

Attest
before
commit

Immutable state layer (DLT)

CeFi CeFi Event Ledger Always present

Universal immutable event store

Authoritative ownership register

Hyperledger Besu · QBFT consensus

Lightweight attestation contracts

DeFi-CeFi Bridge Service

Listens for confirmed token events on the DeFi Token Chain, translates to canonical format, and submits to the CeFi Event Ledger. Carries source transaction hash and contract address for cross-chain audit linkage.

DeFi DeFi Token Chain DeFi TA module

Tokenised fund register

ERC-3643 compliance contracts

Private Ethereum-compatible chain

On-chain audit trail

06 Deployment & delivery Source code supplied

YAML cloud deployment manifests

Commercial perpetual source licence

Client-deployed infrastructure

Azure UK / Europe reference

Event sourcing + CQRS Write path to DLT via domain events. Read path from PostgreSQL. DLT record governs on discrepancy.

Technology agnostic DLT Platform abstraction isolates all components from the underlying ledger technology.

Deterministic reconstruction Complete state rebuildable from genesis by replaying the event stream.

Regulator observer nodes CSSF, FCA, or auditors can operate independent nodes with verified ledger access.

Dual DLT environments CeFi Event Ledger for universal event recording. DeFi Token Chain for tokenised funds. Bridge service keeps one unified event store.

PII-free on-chain records No personally identifiable information on the DLT. Entity identifiers and hashes only. GDPR erasure resolved by removing the off-chain identity mapping.

DLT Deployment Configuration

Three independent models define each deployment.

Each model represents a design decision that can be configured per deployment without altering the core architecture. The default SMART-TA institutional deployment combines CeFi custody, DLT as the authoritative register, and off-chain business logic execution.

Custody model

Who holds the cryptographic keys?

Default CeFi (Custodial)

Platform operator or appointed custodian manages keys on behalf of investors. Investors interact through the application layer.

DeFi TA variant DeFi (Self-Custody)

Investors hold their own keys and interact with the DLT directly, subject to on-chain compliance controls.

System of record

Where is the authoritative register?

All deployments DLT is the authoritative register

PostgreSQL serves as the operational read layer for UI, reporting, and downstream processing. The DLT record governs on discrepancy. Continuous reconciliation validates consistency.

Business logic execution

Where do rules run?

Default Off-chain execution

All business rules, compliance logic, and trade validation execute in the platform microservice layer. State transitions committed to the DLT after off-chain validation.

DeFi TA variant On-chain execution

Selected compliance logic executes as smart contracts on the DeFi Token Chain via ERC-3643 transfer rules and eligibility enforcement.

Adoption pathway

One platform, three stages of operational confidence.

The platform architecture does not change at each stage. What changes is what the client trusts, uses, and formally designates as authoritative within their own governance.

Immutable audit

Legacy migration · Validation period

The DLT records all state transitions. The client uses the DLT primarily as a cryptographic audit trail while validating completeness and accuracy against operational systems. PostgreSQL remains the client’s working operational reference.

Tamper-evident record keeping Cryptographic proof of every state change Immutable audit trail

Verified register

Steady state · New fund launches

The client formally adopts the DLT as the authoritative register for ownership state. Continuous reconciliation becomes verification rather than validation. The DLT is the system referenced for position verification, regulatory reporting, and dispute resolution.

Authoritative ownership register Deterministic reconstruction Zero-reconciliation operations

Tokenised register

Tokenised fund structures

The fund’s legal documentation recognises tokens as the unit of ownership. The DLT register is the legal register. Operations are expressed as token operations via smart contracts, with on-chain compliance enforcement through ERC-3643.

On-chain settlement Programmable compliance Digital asset interoperability

No platform migration required Clients move between stages by changing their operational governance designation, not by upgrading the platform. The architecture is the same from day one.

Design principles

Eight principles governing every layer.

Immutability as infrastructure

Every state-changing event with regulatory, legal, or audit significance is committed to an immutable ledger. All components inherit this capability.

Operational separation

Mutable operational data stays in microservice-owned schemas. The DLT layer is the authoritative record of state transitions, not a replacement for operational databases.

Attestation before commitment

No state transition reaches the DLT without an attestation record establishing who authorised the change, under what governance model, and with what evidence.

Deterministic reconstruction

The DLT event stream for any fund, share class, or tenant is sufficient to reconstruct complete current state from genesis. No hidden off-chain adjustments.

Correction as first-class citizen

Corrections, amendments, and reversals are explicit, auditable events. The original record is never modified or deleted.

Technology agnosticism

The DLT layer is accessed through a platform abstraction interface. Components are not required to share the same DLT backend.

Regulatory alignment by design

The architecture satisfies DORA, CSSF, FCA SYSC, and Luxembourg professional secrecy requirements without per-deployment customisation of the data layer.

Source code delivered

Commercial perpetual source licence. Clients deploy on their own infrastructure. Obligations end at the software boundary.