Tokenise-Broker — System Architecture Overview
The Tokenise-Broker platform is designed as a modular, service-oriented ecosystem.
Our goal is to keep core domains logically separated so that each service can evolve independently while maintaining strong integration through clearly-defined APIs.
This approach improves:
- scalability (services can scale independently)
- development speed (teams work on separate domains)
- reliability (failures are isolated, not system-wide)
- maintainability (each service has a focused responsibility)
- flexibility for future integrations and external partners
Rather than building one large monolithic backend, Tokenise-Broker follows a distributed service architecture where responsibilities are separated into independent functional services.
Platform Components
Below is a high-level description of the services shown in the architecture diagram.
1) Investor Website (Front-End)
The investor-facing web application used by end-users to:
- register & onboard
- access investment dashboards
- interact with broker services
Communicates directly with Backend-Core via secure APIs.
2) CMS (Content Management System)
https://cmsportal-dev.tokenise.io
Responsible for:
- website content management
- static & dynamic page management
- publishing announcements and updates
Separated to avoid coupling marketing content with core business logic.
3) Admin Panel (Broker Admin Console)
Used for:
- operational administration
- user & account management
- reviewing platform activities
This panel connects directly to Backend-Core.
4) Notify Service + Admin Panel
Central notification service for:
- email delivery
- SMS delivery
- event-based messages
Shared across all platform services.
5) VERO Compliance (KYC)
Responsible for:
- KYC / AML processing
- risk scoring
- compliance review workflows
Designed as an independent regulated domain.
6) PayBlock (Payments Gateway Orchestration)
https://payblock.veropulse.com
Central gateway for:
- deposits & payment routing
- multiple PSP integrations
- unified payment API for all services
Other services do not talk directly to PSPs — only via PayBlock.
7) Agent (Accounting / OMS)
Status: not implemented yet
Planned responsibilities:
- internal accounting
- balance tracking
- OMS / execution coordination
8) Backend-Core
https://api-dev.tokenise.io/swagger/index.html
Acts as the business orchestration layer.
Responsibilities:
- coordinating flows between services
- applying business rules
- aggregating data for applications
- routing authenticated operations
Does not replace domain services — it coordinates them.
Next Steps
Each service will receive its own dedicated documentation page.
Navigation will remain simple initially, and content will be added gradually as components mature.