Platform Architecture
The three layers
XYB is structured in three layers, each responsible for one part of the system:
Component the individual financial capabilities: Deposits & Wallets, Payments & FX, Credit, Interest, Cards. Each owns its own database and API; no other layer or capability reads or writes it directly.
Orchestration the shared services capabilities configure against instead of reimplementing: product configuration, policy, and workflow.
Experience how the platform is surfaced to a person: the console, and the mobile and web apps.
Data flows upward and outward, not sideways. A capability posts its transactions to the Ledger and exposes an API and an event stream. Orchestration services read and write configuration that governs how those APIs behave, without touching a capability's data directly. Experience surfaces read from Orchestration and the capabilities' APIs — they don't hold their own copy of anything.
Integration through adapters
Anywhere XYB needs to talk to something outside the platform, a payment rail, a card network, an identity or KYC provider, an open banking connection, an email or SMS channel, that connection is a self-contained adapter, not logic embedded in the capability using it. A capability calls its own internal contract; a configuration setting decides which adapter, and which real-world provider, handles the request.
Adapters register the specific features they support rather than a generic category, across five areas: Payments & FX, Accounts & ledger, Identity & verification, Open banking, and Communications. This lets more than one provider support the same feature side by side, and lets an integrator register their own existing provider relationship as an adapter, evaluated the same way as any built by XYB.
How backend services power product configuration
A product is what an entity is entitled to use. It's assembled from one or more backend services — Accounts, Cards, Policy management, and so on — each independently versioned, with its own configuration: the Accounts service configures default currency and wallet currencies, for example, while Policy management configures risk rules and approval requirements.
A product moves through a draft → active lifecycle; assigning an active product to an entity is what unlocks account creation and onboarding for that entity. Nothing downstream is available until that assignment happens — the backend services power the product, but the product configuration is what turns them on for a given entity.
Orchestration: policies and workflows
Policy is structured as a hierarchy: a Domain (e.g. Payment Processing) contains Policy Types (e.g. Risk Rule), each with a Policy Definition and a versioned, current setting. Each policy type declares an evaluation strategy and a default evaluation service — the capability that actually executes the rule. Capabilities call out to policy rather than hardcoding limits or approval logic themselves.
Workflows are named, ordered definitions of how something moves through the platform. Onboarding is one instance — a sign-up runs through an ordered list of steps (e.g. verify phone, choose product, link device), evaluated once per sign-up. Payments is another — named flow definitions (an ACH flow, an internal payment flow) define the shape a payment takes, with policy governing what's allowed inside it: scheme, rail, and whether an operation requires approval.
Approvals are a cross-cutting workflow concern: a dedicated four-eye service raises and tracks approval requests from any capability that needs one, rather than each capability building its own approval logic.
How operators work: the console
The console isn't one application: it's a shell that loads one interface module per capability or orchestration service, so its structure mirrors the backend's own boundaries: a ledger module, a payments module, a policy module, an access-management module, each shipped alongside its own service. It reads live data directly from the capabilities and orchestration services underneath it — there's no separate reporting copy that can drift out of sync.
A menu item's visibility depends on two independent conditions: the underlying service is deployed to that environment, and the interface module that renders it is deployed and registered there. Both have to be true — a service can be fully live with the right permissions granted, and its screen still won't appear if the module registration hasn't happened.
Access within the console follows the same permission model as everywhere else: actions requiring a permission the operator lacks are hidden or disabled, not shown and then rejected. Roles split into two kinds — console roles, fully editable, governing what an operator can do; and roles corresponding to a customer-side access level, which are platform-managed and read-only wherever they're provisioned.
How end users work: mobile and web apps
Mobile and web apps are deployed independently of the backend — an app update doesn't require redeploying any underlying service, and the frontend scales separately from transaction processing. What an app actually does for a given user is determined entirely by product configuration and workflow, not hardcoded into the app itself: the same onboarding step sequence that orchestration defines is what the app walks a new user through, step by step, at sign-up.
Apps resolve the calling user's identity server-side from their own session, rather than trusting a client-supplied identifier — the same request that reaches a capability's API from the console (where an operator can act on someone else's record) carries a different, higher-trust permission scope than the equivalent request from an end user's own app acting only on their own record.
Both mobile and web apps are white-labeled to the operating institution, not to XYB — the branding is a configuration concern, the same as everything else at this layer.
Last updated