> For the complete documentation index, see [llms.txt](https://docs.xyb.co/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.xyb.co/the-platform/xyb-platform-overview/our-solution-offerings.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.xyb.co/the-platform/xyb-platform-overview/our-solution-offerings.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.