> 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/xyb-banking-orchestration-platform-overview.md).
# XYB Banking Orchestration Platform - Overview
XYB offers a banking orchestration platform: it lets you build or expand your financial product ecosystem by configuring composable components: **deposits and wallets**, **payments and FX**, **credit**, **interest**, and more. That means you can build a financial product stack from scratch, or add new capabilities to what you already run, without disrupting it.
Around these capabilities sits a shared operating layer: **access control, product configuration, and an automation engine that any capability can plug its own actions and triggers into.** Connections to outside providers: payment rails, card networks, identity verification, run through adapters, so you can bring the providers you already work with, or switch one later, without touching anything else.
XYB's capabilities are built to compose with each other from the start. They share one canonical model for the core objects (customer, account, transaction, balance), they all post through the same Ledger, and they can all register actions with the same automation engine. Adding a capability means configuring it against data that already exists, not building a new integration.
| EXAMPLE: A lending feature added to an existing wallet product
A fintech already uses XYB for customer wallets and the underlying balance records in the Ledger. They want to add a “pay in 3 installments” option at checkout.
- They configure a new credit product: repayment schedule, interest terms, eligibility rules without touching how wallets or the Ledger are already set up.
- When a customer takes the offer, the credit contract is created and the payments capability disburses the funds into the same wallet that already exists.
Result: one new capability was switched on; nothing already running had to be re-integrated.
|
| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### How does the XYB platform work?
The platform has three layers:
* Component layer: the core capabilities (Deposits & Wallets, Payments & FX, Credit, Interest, and the Ledger)
* Orchestration layer: shared services used by every capability: access control, product configuration, and an automation engine other services register actions and triggers with.
* Experience layer: how everything above is actually surfaced to a person: the console, your customer web app, and your customer mobile app.
Solutions aren't a fourth layer stacked on top: they're named combinations that draw from all three layers at once, packaged around a specific use case. Adaptive Digital Banking, for example, composes capabilities (Component), the workflows that connect them (Orchestration), and the customer-facing screens that result (Experience) into one named, buyable thing.
| Use Case: A company runs payroll for employees across multiple countries from a single payroll batch.
- Component layer: Deposits & Wallets holds the company's funding balance, and Payments & FX executes each employee's payout.
- Orchestration layer: a workflow routes each payment through the correct rail for that employee's country, swappable per corridor without changing the payroll product itself and holds any batch over a set threshold for a second approver's sign-off before release.
- Experience layer: an operator reviews and approves large batches in the console, while the company's own finance team just sees "payroll sent" in their app, the rail differences per country stay invisible to them.
Result: one payroll run, many countries, and the only thing that changes per corridor is which rail handles it.
|
| ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
#### Where it's used
Current documented use cases:
* A full-stack digital bank: ledger, accounts, payments, and credit together.
* Embedded payments inside another company's product.
* Credit for e-commerce (buy-now-pay-later and similar).
* A reconciliation layer sitting over an existing core banking system.
* A fully white-labelled banking app.
Adaptive Digital Banking (Solutions section) documents the first of these a full-stack digital bank as a worked example, including the specific capabilities it composes and a step-by-step tutorial.
---
# 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/xyb-banking-orchestration-platform-overview.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.