White-label trading platform and B-Book engine development.
For founders and brokers who want to own their trading infrastructure.
Renting a white-label platform is the fast way to start a brokerage. Owning one makes sense later, when fees, limits on customisation or reliance on one vendor cost more than building. I have not shipped a complete proprietary trading engine in production. I work on the systems around one every day at a live broker, and this page is how I would take on yours.
Closest work in production
Job · CFI FinancialIn production
Payments and crypto back office at a live broker
Wallet payment methods in production, crypto back-office APIs with field-level permissions, and cross-service debugging on an event-driven platform at CFI Financial.
- 3 wallet payment methods live
- 26 tickets in the first two months
- 7 services and shared libraries
What I have run in production around a trading core
Broker back-office APIs
Order and transaction views, maker-checker approvals, paginated lists and CSV or PDF exports, behind role and field-level permissions.
Real-time risk monitoring
Loss and equity rules checked every few seconds on live accounts, with safeguards that refuse to act on numbers that do not add up.
Multi-tenant services
A payment gateway where every merchant has its own credentials, keys and profile, isolated from the others. The same discipline a multi-brand platform needs.
Deposits and refunds
Apple Pay, Google Pay and Benefit as deposit methods at a live broker, with webhooks and refunds, built so a payment is never credited twice or lost.
Crypto and multi-asset precision
8-decimal amounts carried correctly through APIs, models and access-control definitions.
Event-driven sync
Client portal and back office kept consistent through a message queue, including the deploy order that keeps both sides working.
What I can build next
The engine and the white-label layer
Not yet delivered as a finished product
This is the part I would design and build with you, and have not yet delivered as a finished product. It starts with a paid technical sprint that proves the core before anything else is built on it.
Price ingestion
Normalised quotes from data or liquidity providers, a markup per client group, and staleness detection so no order is ever filled against a dead price.
Order lifecycle
Market, limit and stop orders as an explicit state machine: every transition recorded, every request idempotent.
Positions, P&L and margin
Realised and unrealised P&L, equity, used and free margin computed by one implementation in fixed-point decimals.
Margin call and stop-out
Deterministic liquidation rules, tested by replaying recorded price sequences before they touch a live account.
B-Book first, A-Book later
An execution interface that starts with internal fills and leaves room for routing selected flow to a liquidity provider, and for hybrid models.
Multi-brand from the first schema
Tenant, brand and legal entity modelled from the start, so adding a white-label client is configuration and not a rewrite.
Before it goes liveA trading engine that holds client money needs independent testing, a security review and legal and regulatory sign-off before it goes live. I plan for those. I do not replace them.
Proof, not promises
- Payments and crypto back office at a live brokerJob · CFI FinancialSenior Backend Engineer on a live multi-asset broker: crypto back-office APIs, maker-checker flows, field-level permissions and payment methods in production.
- MT5 Manager API service and real-time risk monitorFreelance · TradersFlow (TRFC)The MT5 integration service and real-time breach monitor for a live prop-trading platform.
- Octopus payment gateway microserviceJob · AppnovationA multi-tenant payment gateway service with per-merchant keys, request signing and key rotation.
How we can work together
Start small. Commit when it works.
Every engagement starts with a written scope. You know what you are getting, what it costs and what is left out before any work begins.
- 01Fixed fee · 1 to 3 weeks
Technical discovery sprint
I review your requirements, existing code and third-party access, then deliver a written architecture, a feasibility and risk report and a milestone plan. Yours to keep, whoever builds it.
- 02Paid by milestone
Fixed-scope MVP build
A defined first release, built in milestones on a staging environment you can use throughout. You pay for delivered milestones, not for hours.
- 03Monthly
Founding engineer contract
I join as your hands-on technical owner: architecture, backend, front end, infrastructure and releases, working directly with you.
- 04Part-time · monthly
Fractional technical lead
You already have a developer or a small team. I own the architecture and the risky parts, review the work and keep delivery honest.
I quote each engagement in USD after a first call. I work from Malaysia with no agency layer, so the budget goes into engineering, not account management. I price on scope and responsibility, and I am not the cheapest option.
- You work with the person doing the work
- Written scope and milestones
- Source code, access and documentation handed over
- NDA on request
- Full-time, 40+ hours a week, from about three weeks after we agree
How we would work
- 01
A short call
A no-obligation conversation about what you are building, what exists already and what success looks like.
- 02
A written scope
What I will build, what I will not, the risks and the price. Larger or unclear projects start with a short, paid discovery sprint.
- 03
Small, visible releases
You see working software early and often, on a staging environment you can click through.
- 04
Handover and support
Source code, access, documentation and runbooks, with ongoing support if you want it.
Questions
- White label or custom build: which should we choose?
- Start on a white label if you are launching: it is live in weeks and the vendor carries the maintenance. Build your own when the fees, the limits on what you can change, or the reliance on one vendor have become the real cost. A custom core is a project of many months with a running cost afterwards, and I will tell you if a white label is still the better answer.
- Have you built a proprietary trading engine before?
- Not a complete one in production. I have built the MetaTrader 5 integration and risk monitor for a live prop firm, and back-office and payment systems at a live broker. An engine is the next layer down, which is why I start with a sprint that proves it.
- How would the project start?
- With a paid technical sprint that proves the core on its own: prices in, orders through, margin and stop-out correct under replay tests. You keep the design and the code, whoever builds the rest.
- B-Book, A-Book or hybrid?
- The design starts B-Book: internal fills against a price feed, with exposure tracked per symbol and client group. The execution interface leaves room to route selected flow to a liquidity provider later. Which model you are allowed to run is a question for your licence and your legal adviser.
- Can one platform serve several brands?
- Yes, if it is designed in from the start. Tenant, brand and legal entity sit in the first schema, with data and configuration isolated per brand. Adding it to a single-brand system later is the expensive way.
- Can we keep MT5 running while the new platform is built?
- Yes, and it is the sensible way to do it. MT5 integration is work I have done in production, so the new platform can run beside your MT5 setup and take over one client group at a time.
- Do you provide liquidity, a licence or a ready-made platform?
- No. I am an independent engineer, not a platform vendor or a regulated firm. Liquidity, custody and licensing come from specialist providers and your own advisers, and I integrate what you choose.
Tell me what you are building.
A few lines are enough: what it is, where it stands today, and what you need from an engineer. The form is just below, or email me if you prefer. I reply within two working days.