Architecture and the open API
A modular core, an event bus and an open banking API: what the platform is built on.
A modular core
DDD with explicit bounded contexts: clients, accounts, payments, lending, deposits, cards, general ledger, treasury. It starts as a modular monolith, and services split out as load grows.
An event bus
Every significant operation publishes a domain event in CloudEvents format through a transactional outbox: to Kafka, RabbitMQ, Pulsar or a webhook.
CQRS for reporting
Heavy read scenarios (reporting data marts, analytics, digital banking) are served separately from the operational write path.
Idempotency
Every public API call and event handler accepts an Idempotency-Key. A repeated request never creates a second operation.
Isolated bank data
A bank is placed in a shared database, a separate schema or a dedicated database. Data isolation is checked on every request, and access is denied on error.
Zero trust between services
mTLS and JWT inside the perimeter, TLS 1.3 outside it, an HSM for PCI DSS and national cryptography keys, a WAF and DDoS protection at the edge.
Observability
Structured logs with an end-to-end correlation id, metrics through OpenTelemetry, and a trace of a single operation across every module it touches.
Open banking API
OAuth 2.1 and OIDC, a sandbox for partner developers, and documentation in OpenAPI 3 and AsyncAPI for both synchronous and event-driven interfaces.
What you can verify in the code
Platform stack
Shared A3 platform modules (accounting, credit bureaus, compliance, AML checks) plug in as internal services with stable APIs, so a bank never integrates them from scratch.
Country specifics (a chart of accounts, payment formats, KYC rules, reporting) plug in through the core's extension points, not through a code fork.
What one installation handles
Ready to see the API
The OpenAPI documentation and the developer sandbox open up to partners after a short conversation about the task at hand.