Kestrel Ops broker back office

Withdrawals, deposits, chargebacks, partner commissions and sales, with server-side rules and an append-only audit history.

Watch the walkthrough →Test report Ask for a live demo

01 / Project facts

What was built, and what is simulated.

Fictional broker; synthetic data throughout.

Ownership: Built by our studio as a proof project. Not client work.
Status: Concept release. Sales module accepted after review; not production-ready.
Target users: Broker finance, compliance, support, sales and operations staff
Stack: JavaScript on Cloudflare Pages Functions; Cloudflare D1 (SQLite); vanilla JavaScript single-page app
Implemented scope: Withdrawals with maker-checker, double-entry ledger, reconciliation, deposits, refunds, chargebacks, KYC restrictions, trading-account transfers, partner commissions, investigations, Sales CRM
Simulated: Payment provider, KYC provider, trading platform (MT5) and message delivery; each behind an adapter
Deliverables: Source code, database schema, specification, acceptance test suite, screenshots, captioned walkthrough
Evidence: Build 9b65cc906b · 1 Nov 2026 · local Wrangler / D1 emulation · test report

The problem

A broker's back office moves client money: withdrawals, deposits, refunds, chargebacks and partner commissions. Approvals get bypassed under pressure, and two people acting at the same moment can pay something twice.

Our contribution

Specification, back-end and database design, staff interface, and an acceptance test suite that injects concurrent changes to prove stale actions are refused.

Departments involved

Product Engineering · Quality & Accessibility · Product Design & Brand · Cloud & Production Ops

02 / Walkthrough

One withdrawal, from request to reconciliation.

Captioned screen recording; no sound needed.

Recorded from build 9b65cc906b on local Wrangler / D1 emulation · captions are part of the video

03 / Screens

Built for the people who run the money.

Select any screen to enlarge it.

**Second approval required**The person who created a withdrawal cannot approve it; the button is disabled and a forced attempt is refused and logged.

**Approved by a second person**The approval, ledger entries and audit record are written together.

**Opt-out blocked dispatch**The client asked not to be contacted, so the SMS was blocked and labelled; delivery is always marked as simulated.

**Reconciliation**Every ledger transaction balances; wallets never go negative.

**Duplicate review**Possible duplicates are proposed for a person to review, never merged automatically.

**Sales report**Cohort and activity views with published definitions.

Lead page on mobile, 390 px — **Mobile at 390 px**The signed-in role stays readable and secondary actions are grouped under "More actions".

04 / Decisions

Problem → decision → evidence.

Two examples from the build.

Stale approvals

Problem

An approval given on one version of a withdrawal must not apply after the amount or beneficiary changes.

Decision

Approvals are bound to the request version; any change voids them, and the state change, ledger and audit are one guarded database write.

Evidence

Acceptance tests change the request between check and write; the tested scenarios refused the stale approval and paid nothing.

Contact after opt-out

Problem

A message approved at 10:00 must not go out if the client opts out at 10:01, or if the lead is reassigned or merged.

Decision

Rules are checked when the request is made and again inside the dispatch claim, bound to the lead's current state.

Evidence

Injected opt-out, reassignment, quiet-hours and merge changes: the tested scenarios blocked, deferred or cancelled the message; none was marked delivered.

05 / Evidence

Tested like money depends on it.

Automated acceptance checks against the API on local Wrangler / D1 emulation.

216automated acceptance checks passing, plus 5 time-zone tests

13AI-assisted review iterations, with a separate AI reviewer

10steps in one end-to-end Sales journey test

0automated axe violations on the checked screens

Build 9b65cc906b · API SHA-256 prefix 4e198ce10c22 · 1 Nov 2026 · environment: local Wrangler with D1 emulation · test report · raw output

Not yet verified: deployed database under real concurrent load, real payment and KYC providers, backup restore drill, Safari and real devices. No independent human security audit has been done. This is a concept release, not a production-ready product.

Need something like this built?

Book a free call →