Fiat rails
On/off-ramp integration,
fiat in and fiat out.
Your users want to buy with a card and cash out to their bank. We build that path. One EU team owns the quote engine, the provider layer, the ledger and the payout flow. You keep the product. We make the money move.
- EU-based engineers
- MiCA-ready architecture
- PSD2 and GDPR aware
Rails
The rails we wire up
Each rail has its own cost, speed and failure mode. We pick per corridor, then hide the difference behind one API.
Card and bank flows in depth sit on our payment gateway engineering page.
| Rail | Direction | What it means |
|---|---|---|
| SEPA & SEPA Instant | In and out | Bank transfers in euro. Instant where the bank supports it. |
| Cards | In | 3-D Secure card top-ups with a chargeback and risk policy. |
| Open banking | In | Pay-by-bank flows with account checks at the source. |
| Payouts | Out | Off-ramp payouts to a named bank account with limits. |
| On-chain legs | In and out | Deposit sweeps and withdrawals across your chosen chains. |
Scope
What we build around the rail
A ramp is six systems that must agree on one number. We build them together, on one plan, with one team accountable.
-
01
Quote and rate engine
One quote covers spread, fee and slippage. The user sees the final amount before they confirm.
- Locked and floating quotes
- Fee schedules
- Quote expiry rules
-
02
Provider abstraction
One internal ramp API sits over every provider. Swapping a vendor is a config change, not a rebuild.
- Single ramp interface
- Per-corridor routing
- Failover order
-
03
Onboarding and limits
Identity checks, tiers and limits live in one place. Rules apply the same way on both directions.
- KYC and KYB tiers
- Per-user caps
- Step-up checks
-
04
Ledger and reconciliation
A double-entry ledger holds every leg. Bank files and chain data reconcile against it daily.
- Double-entry core
- Bank statement match
- Break reporting
-
05
Payout and refund paths
Off-ramp is the hard half. Failed payouts, returns and refunds need a path that ops can run.
- Return handling
- Manual review queue
- Refund policy engine
-
06
Widget and API surface
An embeddable ramp widget plus a clean API. Your app keeps its own look and its own session.
- Embeddable widget
- Webhook events
- Sandbox keys
Delivery
How the work runs
Compliance does not wait for the end. It runs beside the build. Nothing has to be unpicked the week before launch.
- 01
Corridor mapping
1–2 weeks
We agree the currencies, chains, providers and limits you need first.
- 02
Provider selection
2–3 weeks
We test candidate rails against your cost, cover and settlement needs.
- 03
Integration build
Iterative
Quote engine, ledger, KYC and payout paths built behind one ramp API.
- 04
Controls and go-live
Runs in parallel
AML rules, Travel Rule data and audit trails, then a staged launch.
Controls
Built to survive review
A ramp touches money, identity and chain data at once. Regulators read all three. We design the controls in from day one, then leave a trail your reviewer can follow.
We are engineers, not a law firm. Your advisers set the scope. We build to it and hand over the technical evidence they ask for.
The wider practice is described on our compliance engineering page. Custody detail sits with wallet and custody engineering.
Engagement
Four ways to buy the work
Scope shifts as you learn. The commercial model should shift with it.
-
Fixed-scope build
One corridor, a fixed price, a dated plan. Best when the scope is settled.
-
Dedicated team
A standing squad with a lead. Best for long roadmaps and steady releases.
-
Staff augmentation
Senior engineers inside your team. Best when you own the plan already.
-
CTO advisory
Rail choice and architecture guidance. Best before you commit to a build.
Questions
Before you brief us
The four things ramp buyers ask first. Ask the rest on the call.
Do you provide the licence or the banking rail?
No. We are the engineering partner. We integrate your provider, bank or licence holder and build the flow around it.
Can we start with one corridor?
Yes. Most teams start with euro in and out. The ramp API is built so new corridors are added later without a rewrite.
What if a provider goes down?
Routing sits in our layer, not theirs. We define a failover order so a quote can fall to a second provider.
Who owns the code?
You do. We build bespoke systems for the client. There is no white-label lock-in and no per-seat fee later.
Tell us which corridor comes first
Bring the currencies, the chains and the volumes you expect. We come back with a rail shortlist, a risk list and a costed plan. No demo theatre.