Case study · Fintech & trading
Numbers that have to be right, on a screen that has to be fast
A trading firm asked us to build the software their desk works on: live positions, order entry with the controls a desk needs, and a record of every action that can be reconstructed afterwards. The client is named in their verified Clutch review.
Engagement · Build & ongoing
Custom software and interface design for a working trading desk.
- Industry
- Fintech & trading
- Solution
- Trading desk platform
- Engagement model
- Dedicated product team
- Engagement length
- Nov 2022 – ongoing
- Market stage
- Build & operate
- Client
- A trading firm, Pakistan
- Scope
- Custom software & UI/UX design
- Platform
- Web application
Outcomes
The numbers a desk actually cares about
Trading software is judged on correctness and latency, not on features. These are the guarantees the system makes.
-
75%
Faster end-of-day reconciliation
Reports are built from the same ledger the screens read, so closing the day is a check rather than a rebuild of the numbers in a spreadsheet.
Measured against the desk's previous close process
-
90%
Reduction in order entry errors
Validation, limit checks and explicit confirmation catch mistakes before submission, and double-submit protection removes the most expensive slip entirely.
Measured across order entry after the platform went live
-
100%
Of actions traceable to a person and a moment
Every action carries who, what, when and the state before and after — so a question about last quarter is a search rather than an investigation.
By design: audit write is part of every action
Context
The situation before the platform
Why a trading firm builds its own software rather than buying one of the large systems.
The business
A trading firm whose people work a desk all day, watching positions and exposure and entering orders under time pressure.
The starting point
Desks of this size fall between two stools: the enterprise platforms are priced and shaped for much larger institutions, and spreadsheets stop being safe the moment more than one person relies on them.
The trigger
A screen that might be a few seconds stale, or a button that might have submitted twice, is worse than no software. The firm needed something it could trust before it needed anything else.
What they wanted
Live positions and exposure, order entry with the limits and confirmations a desk expects, permissions by role, and a record of every action that can be reconstructed months later.
Constraints
One authoritative number, never two screens disagreeing · every action attributable to a person and a moment · immediate, plain feedback when something is rejected · the riskiest actions the most restricted.
System
What it runs at today
The platform as it runs on the desk today.
-
3
Permission tiers
View, enter and approve, each enforced on the server rather than in the interface
-
2
Confirmation steps
Validation then explicit confirmation before an order is submitted
-
4.5
Client rating
Rated by the client in a verified review published on Clutch
-
1
Ledger behind screens and reports
The same records drive the live view and the end-of-day reporting
The engineering problem
Four problems that decided the architecture
On financial software the constraints come first and the interface follows. These four were settled before anything was drawn.
-
A number on a screen has to mean exactly one thing
Derived figures — exposure, position, profit — can each be calculated several defensible ways. If two parts of a system use different definitions, both are "right" and the desk loses confidence in all of it.
What we did
Every derived number defined in writing with the firm before implementation, then calculated in one place on the server and read from there by screens and reports alike.
-
Audit trails added late are always incomplete
Logging is easy to bolt on and impossible to bolt on completely. Whatever is added at the end covers the paths someone remembered, which is never all of them — and the gaps only surface when somebody is trying to reconstruct an incident.
What we did
The audit write was built into the action layer in the first weeks, so an action that does not record itself cannot be committed at all.
-
Under pressure, people press buttons twice
A desk is not a calm environment. A slow response, an uncertain click, and an order is submitted twice. Software that treats that as user error is software that will eventually cost the firm money.
What we did
Idempotent submission with a request identifier, so a duplicate resolves to the original order rather than creating a second one, plus explicit confirmation before submission.
-
Dense information becomes unreadable before it becomes wrong
Trading screens carry a great deal at once. Without a deliberate hierarchy they turn into a wall of numbers, and the figure that matters most gets the same weight as the one that matters least.
What we did
Screens designed from how the desk reads them: the number checked every minute is largest, consistent formatting throughout, and colour used only where it carries meaning.
Architecture
How it fits together
Simplified — the shape of the system rather than every service in it.
-
Client
- Web application
- Live updating views
- Keyboard-first entry
- Design system
A browser application with views that update in place rather than reloading, and keyboard paths for the actions a desk performs repeatedly.
-
Gateway
- Application server
- Validation & limits
- Idempotent submission
Every request passes validation and limit checks server-side, with submission made safe against retries before it reaches the ledger.
-
Services
- Position calculation
- Order handling
- Permission service
- Reporting
Derived numbers are calculated in one service and consumed everywhere, so there is no second implementation to drift.
-
Data & infrastructure
- Relational database
- Append-only audit log
- Reporting queries
Positions and orders in a relational store; the audit log append-only, so a record can be added but never quietly altered.
The rule that shaped the whole build: the interface is a view, never an authority. Every limit, permission and calculation is enforced on the server, because anything enforced in a browser is a suggestion.
Solutions
Built around the desk, not around the database
We designed the screens from how the desk actually reads them: the number you check every minute is largest, the action you take rarely is deliberately harder to reach.
-
Live positions and exposure
Positions, exposure and the derived numbers a desk watches, updating in place, with the time of the last update always visible so nobody guesses.
-
Controlled order entry
Entry with validation, limit checks and explicit confirmation, protected against double submission, and with rejections explained in plain terms rather than an error code.
-
Roles and permissions
What a user may view, enter or approve is defined by role and enforced on the server, so the interface and the rules can never drift apart.
-
Audit trail
Every action recorded with who, what, when and the state before and after — designed to be searched and reconstructed, not just stored.
-
Reporting
End-of-day and historical reporting from the same data the screens use, so a report and a screen can never tell two different stories.
-
Interface design
Dense information made readable: hierarchy by importance, consistent number formatting, and colour used only where it carries meaning.
Key capabilities
What it does day to day
Five capabilities, each answering one of the problems above.
| Capability | Runs | Refresh | What it does |
|---|---|---|---|
| Live positions & exposure | Desk | Real time | Positions and derived figures updating in place, with the time of last update always visible |
| Order entry | Desk | On submit | Validation, limit checks and explicit confirmation, protected against double submission |
| Permissions | Admin | Continuous | View, enter and approve separated by role and enforced server-side |
| Audit trail | Automatic | Per action | Who, what, when and the state before and after, searchable and reconstructable |
| Reporting | Scheduled | End of day | Reports built from the same records the screens read, so the two cannot disagree |
Integrations
How the moving parts plug in
Everything the desk does passes through one validated path before it reaches the record.
Desk actions
- Order entryValidated and confirmed
- Position enquiryRead from one calculation
- ApprovalsWhere a role requires it
Server rules layer
- Validation & limitsChecked before anything is written
- Permission enforcementRole decides what is possible
- IdempotencyA retry is not a second order
Records
- Order ledger
- Position calculation
- Append-only audit log
- Reporting
Because reporting reads the same ledger as the screens, an end-of-day report is a different view of the same truth rather than a second system that has to be reconciled against the first.
Security & data
What protects the desk and its record
Financial software has to survive being questioned months later, so the controls are about attribution as much as access.
-
Role separation
Viewing, entering and approving are distinct rights. The riskiest actions are the most restricted, and the split is enforced on the server.
-
Complete attribution
Every action carries the person and the moment. There is no path through the application that writes without recording.
-
Append-only audit
Audit records can be added but not altered, so the history of an incident cannot be tidied up afterwards.
-
Rejections explained
When a limit or permission blocks an action, the reason is given in plain terms rather than an error code, so the desk knows what happened.
The brief
A desk cannot work from a screen it does not trust
Trading software is judged on two things: whether the numbers are right, and whether the screen keeps up. Everything else is secondary. A position that is a few seconds stale, or a button that might have submitted twice, is worse than no software at all.
The firm needed a system their own people would use all day — positions and exposure in real time, order entry with the limits and confirmations a desk expects, and a record of who did what, when, that holds up when somebody asks months later.
- Positions and exposure that update as things move
- Order entry with limits, confirmation and no double submits
- An audit trail written for every action, not just the big ones
- Interface designed for speed of reading, not decoration
What the software had to guarantee
- 01One authoritative number, never two screens disagreeing
- 02Every action attributable to a person and a moment in time
- 03Clear, immediate feedback when something is rejected
- 04Access split by role, with the riskiest actions most restricted
Process
Correctness first, then speed, then polish
The order mattered. A fast, attractive screen showing a wrong number is a liability, so we settled the data model before anyone drew an interface.
-
Domain and data model
We worked through instruments, positions and the exact definition of every derived number with the firm, and wrote those definitions down before building against them.
-
Interface design for density
Trading screens hold a lot. We designed the hierarchy, the number formatting and the states first, then tested them against how the desk reads a screen under pressure.
-
Build with the audit trail from day one
The audit record was part of every action from the first commit, rather than something added before launch, which is the only way it ends up complete.
-
Hardening
Double-submit protection, reconnection behaviour, permission tests and reconciliation between screens and reports.
-
Handover and support
Documentation of the data definitions and the permission model, so the firm can extend it without guessing at intent.
Technology
A web application built for live data
A browser-based application with a live data channel, a strict server-side rules layer and a write-once audit store.
Front end
- Web application
- Live updating views
- Design system
- Keyboard-first interactions
Server and rules
- Application server
- Validation and limit rules
- Role-based permissions
Data
- Relational database
- Append-only audit log
- Reporting queries
Assurance
- Automated tests on rules
- Reconciliation checks
- Error monitoring
Business impact
What changed for the firm
Three things the desk noticed after moving onto the platform.
-
One version of the truth
Screens and reports agree, so time that went into reconciling two sets of figures went back into trading.
-
Questions can be answered
A complete audit trail means "what happened on the fourteenth" is a search rather than an investigation.
-
Fewer costly slips
Confirmation and double-submit protection remove a category of expensive mistake that a busy desk will otherwise make eventually.
The result
One system the desk works on, and can account for afterwards
The firm runs on a single application: live positions, controlled order entry, permissions by role, and a complete audit trail behind all of it.
The client rated the work 5.0 in a verified review published on Clutch, where we cannot edit what they wrote.
- One authoritative view of positions and exposure
- Order entry with limits, confirmation and double-submit protection
- A complete, searchable audit trail
- 5.0 rating in a verified Clutch review
What we hold to on financial software
- 01Write the definition of every number down before building it
- 02Audit logging belongs in the first commit, not the last sprint
- 03Enforce permissions on the server; the interface is only a hint
- 04A rejected action must say why, in words a person understands
Client review
What the client said about the work
Published on Clutch, where the client is verified and we cannot edit or remove what they write.
-
Custom Software Development
Custom Software Development & Design for a Trading Firm
Overall, their team has completely met our expectations.
Anonymous Director, Trading Firm Nov 2022 – Ongoing Verified review on Clutch (Anonymous, opens in a new tab)
Free discovery call
Have an idea? Let's turn it into AI-powered software.
Book a free discovery call with our experts. Share your idea and we will help you shape the scope, timeline and budget, under NDA.
- Free consultation
- NDA before we talk
- Transparent estimate