The Olympus infrastructure.
A small set of layers, each with a clear job, shared by every Olympus product.
The layers behind every Olympus product.
The layers.
Banking
Accounts, balances and the account model. Business accounts by currency, subaccounts and virtual accounts sit on a set of accounting records.
Every business gets accounts organised the way it runs: an operating account, subaccounts for tax, payroll or a project, and account details in other currencies where your plan includes them. You see one balance per account, and the history behind it.
Payments
The movement layer: transfers, payment links, QR, payouts and settlement, each with limits, approvals and idempotency.
A payment link, a QR scan, a payroll run and an API payout all go through the same movement layer. Each is checked against limits and approvals, sent by the right route for the country and recorded when the route confirms it.
Accounts
The record of who holds what. Balances are derived from account records, so history and balance cannot disagree.
Balances are never typed in. They are worked out from the entries posted to an account, so when you want to know why a balance is what it is, the answer is in the history.
Cards
Card issuing is through issuing partners. Olympus holds the card record, the per-card controls and the spend posting.
Olympus issues cards through issuing partners. Olympus keeps the record of each card, the limits and controls you set on it, and posts the spend to your account when it clears.
Merchant
Acceptance channels, settlement, disputes, approvals and reporting for merchants.
Merchants take payment by QR, payment link or checkout, follow settlement into their account, deal with disputes and see reporting by day and by channel.
APIs
Scoped keys, sandbox and live environments, idempotency and signed webhooks over the same capabilities.
What you can do in the workspace you can do with a scoped key. Sandbox and live keys are kept apart, requests carry idempotency keys, and events reach your server as signed webhooks.
Identity
Verification of people and businesses, including biometric identity checks and beneficial-owner declarations, before accounts open.
Before an account opens, a person is verified with a government ID and a selfie, and a business declares its directors and beneficial owners. This applies whichever product you started from.
Risk
Device intelligence at sign-in and payment, rate limits, and holds where fraud or financial crime is suspected.
Device signals at sign-in and on payments, limits on how quickly requests can arrive, and the ability to hold funds while a person looks into a concern.
Compliance
Sanctions screening, transaction monitoring against reporting thresholds and retention aligned to the regulator.
Names are screened against sanctions lists, transactions are monitored against reporting thresholds, and records are kept for as long as the regulator requires.
Operations
Statements, bulk and scheduled payments, audit logs and reconciliation: the back-office layer.
The everyday layer that keeps a business running: statements, bulk and scheduled payments, an audit log of who changed what, and reconciliation that only raises what does not match.
What we mean by infrastructure.
Most of what you see of Olympus is a screen: a balance, a payment form, a card. Underneath, those screens lean on the same few pieces of plumbing. When you send money, something checks that you are allowed to, something chooses how it travels, something records what happened and something tells you the result. Infrastructure is the name for those pieces.
We build them once and share them. A payment made in the web app, one made by a customer through a link and one made by your own software through the API all go through the same checks and end up in the same records. That is why your balance, your statement and your reconciliation report agree with each other, without anyone lining them up by hand.
It also makes new things quicker to add. A card, a payout or a new country reuses the layers that already exist instead of arriving with a system of its own, and it inherits the identity checks and monitoring that come with them.
Follow one payment.
A customer pays a business through a payment link. Here is what happens, and which layer does each part.
The customer opens the link
They see the amount, the reference and who they are paying, then choose from the payment methods that are available in the business’s country.
The request is checked
Olympus confirms that the link is valid, that the amount is within limits and that the business account is verified and in good standing. If the same request arrives twice, its idempotency key makes sure only one payment is created.
A route is chosen
The country and the method decide whether the payment goes to a card processor, a mobile-money network or a bank rail. A route that has not been tested end to end stays switched off, so nothing is sent down a path we have not verified.
The partner confirms
The payment stays in processing until the processor or bank confirms it. Olympus waits for that answer rather than assuming one.
The records are written
Entries are posted to the accounts involved: the amount, the fee and what is left for the business. The balance changes because the records changed.
Everyone is told
The customer sees the result. Your server receives a signed webhook. The payment appears in your workspace, your statement and your exports, all from the same record.
Design principles.
One platform
Every product posts to the same set of accounting records. There is no side system to reconcile against.
Data-driven country rules
Tax engines, payment methods and settlement rails are configured per country.
Controls alongside the platform
Identity, risk and compliance are shared layers, so a new product cannot skip them.
Fail-safe routing
A route stays switched off until it has been verified end to end.
Who builds on it.
The same layers serve very different customers.
Businesses
Use the workspace as it is: accounts, payments, cards and a team with roles and approvals. Everything below it is already in place, and you never have to think about it.
Business BankingPlatforms
Offer accounts, payments and cards inside your own product. Your users go through the same identity checks and controls as anyone else, and you keep the customer relationship.
Embedded FinanceFinancial institutions
Partners that want modern account and payment capability without building the platform first can talk to us about how the layers connect to what they already run.
Financial InstitutionsWhat is available where.
Not every layer is open in every country. Which products, currencies and payment methods you can use depends on your plan, your onboarding and the regulatory conditions that apply in your region, and we say so on each product page rather than promise more than we can deliver.
Infrastructure questions
Is infrastructure something I buy separately?
No. It is what the products run on. You use it through Business Banking, Payments, Cards, Merchant Services and the API, and you are charged for those, not for the layers.
Can I use the layers without the Olympus apps?
Many of them, through the API, where your plan and region allow it. Scoped keys, a sandbox and signed webhooks are there for that. See the developer pages.
How is my data kept apart from other customers’ data?
Database policies isolate one customer’s data from another’s at the data layer, and data is encrypted in transit and at rest. The security page lists the measures in detail.
Does Olympus connect to my bank or accounting software?
Olympus connects to bank and accounting integrations to sync transactions and match expected payments. See integrations for what is supported.