Modular digital banking architecture

White-label web and mobile applications use banking services for accounts, balances, payments, cards and onboarding. Operational interfaces connect these workflows with support, compliance, accounting and reporting.

Modules describe business capabilities; services implement technical responsibilities. A service, a module, a provider integration and an API endpoint are different units and should not be counted interchangeably.

An active service is running in a particular deployment during an identified period. The broader catalogue includes deployable modules and integration capabilities, including previous implementations; it is not the number of services running simultaneously for every customer.

Transaction volume describes the value of transactions processed through software over a period. It is not Bastion revenue, assets under management or customer funds held by Bastion.

Synchronous service requests retrieve information or ask another service to perform work and return a response. Bastion uses gRPC for these internal request-response interactions.

Asynchronous events serve a different purpose: publishing changes for consumers to process separately. Persisted message delivery, recorded attempts and retry mechanisms support this flow. The architecture uses both patterns; not every interaction is event-driven.

An API is an interface contract. An endpoint is a particular operation exposed through an interface. Provider APIs remain distinct from the APIs consumed by customer applications.

The double-entry ledger records each posting with debit and credit accounts and an amount. Pending movements describe work before final posting; transaction states and provider references connect execution with accounting.

Reconciliation compares internal records with provider evidence. A provider request, a completed payment, a ledger posting and a matched statement entry are related but distinct steps. Keeping those states explicit supports exception handling and operational investigation.

Integration services translate provider-specific APIs, callbacks and processing states into banking workflows. This separation helps preserve customer applications when adding a provider or changing an execution route.

Provider neutrality does not mean every provider offers identical functionality. Account models, supported currencies, approval processes and settlement behavior still require assessment and mapping.

Deployment options include shared cloud, dedicated cloud, customer-owned cloud and on-premises environments. Capacity planning must account for service workloads, shared data dependencies and external provider limits.

Staged processing, work reservation, retries and transaction references support recoverable workflows. They do not remove the need for monitoring, exception handling, tested recovery procedures and deployment-specific capacity validation.

The Bastion Support Assistant is production-ready, with core logic, customer context, escalation and audit capabilities complete. Rollout is due in the coming days.

Reconciliation agents and data-analysis agents are used in production to support reconciliation work and operational analysis. Availability, data access and workflow scope depend on the selected deployment.

AI assistance operates within the institution’s access, review and audit controls. It does not bypass approvals or imply autonomous payment execution, ledger posting or regulatory decisions. Permitted data, model access, human oversight and operational responsibility must be agreed for each use case.