Financial platforms built for accuracy, compliance, and trust.
In capital markets, a late number or a compliance gap isn't a bug, it's a liability. We build investor-relations, market-intelligence, and trading platforms where data is accurate, every action is auditable, and sensitive financial information is protected end to end. Regulated-market grade, from the first version to real scale.
The constraint
On a market platform, the software is three things at once. It is the product people pay for, it is the record of what actually happened, and it is the evidence if a regulator, an auditor, or a counterparty asks later. Those are three different jobs with three different failure modes. A product failure loses a customer. A record failure loses a number nobody can reconstruct. An evidence failure surfaces months later, in front of exactly the wrong audience. Most platforms are built as though they were one job, and the other two are discovered under time pressure.
Two of the financial platforms we have built, chosen because each one turned on a different constraint.
Investor relations for ASX-listed companies
A listed company's shareholder register is competitively sensitive, and competing issuers sit on the same platform. The platform runs the investor relations function for ASX-listed companies, which means the platform holds, for each client, exactly the material a rival would most like to see.
The usual answer to multi-tenancy was rejected here. One shared database with a tenant column holds its separation only as long as every query, every join, and every background job remembers the filter, and the failure is silent. A missing filter does not throw an error. It returns more rows.
What was built instead is a database per company, created in the same automated onboarding that creates the company, with every request resolving which company it belongs to before a connection is made. Each client also has its own identity pool, and application components connect with credentials scoped to the little they need. Isolation is a property of the structure rather than a discipline every engineer has to maintain.
On top of that structure, investor reporting runs about 70 per cent faster than the manual process it replaced.
Blackhedge, a real-time market platform
A four for one split takes a stock from two hundred to fifty overnight, and nothing has happened. Every holder has four times the shares at a quarter of the price. A system reading raw prices sees a seventy-five per cent collapse. A momentum model reads a crash, a volatility model reads an event, and an alert fires on a move that never occurred.
Blackhedge stores two price series per symbol, and the event itself. Models read the adjusted series, so history is continuous across the split. Statements and positions read the unadjusted one, because what somebody paid on the day is still what they paid. The models read a market that existed, and the records show what actually happened.
The order path got the same care. An order, once placed, cannot be unplaced, so a retry that places a second order has doubled a position rather than recovered from a failure. Every step on that path is built to be safe to repeat.
Blackhedge was acquired by Surmount AI in January 2024.
These are two of the platforms we have worked on in this sector. The full set is in our case studies, including work we cannot name.
What we would expect to deal with on your platform
Not a service list. Four problems that show up on most capital-markets platforms, and the decision we made when each showed up on ours.
Market data is metered and rate limited, so a design that scales with users runs out of budget before it runs out of users. One fetch serves every watcher of the same symbol.
A trading signal has a shelf life. Delivered late, it is an instruction to act on something no longer true, so an expired signal is dropped rather than delivered.
Real-time exchange data carries entitlement conditions on who may see it and how it may be displayed. That is a legal constraint, not a technical one, and it belongs in the data model rather than in a contract in a drawer.
Competing customers on one platform makes isolation the primary design problem rather than an infrastructure detail.
Security and control design
The material that needs protecting on a market platform is not only private, it is tradeable. Knowing that a specific person is about to place a large order, before it reaches the venue, is actionable information about an identifiable individual. Standing internal access to live order flow is not a privacy risk in the ordinary sense. It is a market abuse surface, and the controls below are designed against that reading.
Isolation is a structural property rather than a filter every query has to remember, so separation between competing clients cannot quietly fail.
Trading credentials are held encrypted and purpose-scoped, and never appear in logs, error reports, or support tooling, because an injection runs with the privileges of the credential it lands on.
Access to live order flow is restricted, time-limited where it is needed at all, and recorded with actor and reason rather than granted as a standing role.
Positions and watchlists are masked by role, because a holdings list is a financial profile and a watchlist is a statement of intent.
Audit trails are immutable, written where the application cannot revise them, and cover the three things questioned afterwards: who approved a release, who assigned or changed an order, and where money moved.
Secrets are held centrally and retrieved at runtime, so a client's own credentials rotate without a deployment.
The scope we declined
Custody sits with the funding partner. Cardholder data is captured by the payment provider and never received. Identity documents stay with the provider whose business that is. Each of those is a category of regulatory obligation that was not taken on rather than managed, and an audit scope never entered is absent rather than reduced each year.
Which trust services criteria this work is judged on
Availability, and not as a percentage in a service agreement. The market opens at a fixed time whether the platform is ready or not. A trading system unavailable at the open has not degraded, it has failed for the day, and the users most affected are the ones relying on it most. That reframes caching as an availability decision, because a rate limit reached at nine thirty is an outage.
Processing integrity belongs to the order path and the ledger. A trade that happened must be recorded exactly once, in the state it actually reached, reconciled against the venue rather than against the platform's own optimism.
Confidentiality, in the unusual form described above. The material is tradeable rather than only private, so confidentiality controls are judged against misuse as well as disclosure.
The boundary, stated plainly. The control set is designed against these criteria rather than mapped to them afterwards, which means an organisation preparing for an attestation is documenting controls that already exist rather than retrofitting them under time pressure. That is a statement about how the platform was built. It is not a claim to hold an attestation, and where a client needs one, the work is theirs to complete with an auditor. We don't claim certifications we don't hold.
What this costs to run
Three things a finance leader should know before committing to a platform like this, each drawn from real work.
Market data spend tracks the symbols the platform follows rather than the number of users watching them, which makes the largest variable cost a number the business sets rather than one the market sets.
Peak capacity is bought by the minute rather than provisioned for the year, so infrastructure tracks real usage rather than the busiest fortnight.
Obligations declined at the start are recurring costs that never begin, including the audit scope, the evidence gathering, and the insurance that follows.
Outcomes we've delivered
How you'd work with us
Pick the level of ownership that suits you.
Staff augmentation
Add senior engineers with financial-platform experience to your team.
Dedicated team
A committed team that runs like your own.
Full delivery
Hand over the build and we deliver it end to end.
Frequently asked questions
How do you handle regulatory compliance and audit requirements?
Audit trails are immutable and written where the application cannot revise them, so every draft, edit, and approval is provable, and approval workflows are role based so nothing goes out unchecked. We are equally precise about what we do not claim: controls are designed against the relevant frameworks and criteria, and where a client needs an attestation, the work is theirs to complete with an auditor. We don't claim certifications we don't hold.
Can you work with regulated markets like the ASX?
Yes. We've built investor-relations and disclosure workflows aligned to ASX requirements, with the validation and approval steps regulated markets expect.
How do you protect sensitive financial data?
By treating it as tradeable, not just private. A holdings list is a financial profile and a watchlist is a statement of intent, so positions and watchlists are masked by role, access to live order flow is restricted and recorded, and trading credentials never appear in logs or support tooling. Isolation between clients is structural rather than a filter every query has to remember.
How quickly can you start?
Usually within one to two weeks, depending on scope and access. We start with a short discovery to agree goals, compliance requirements, and data access before any code is written.
Building a financial platform that has to be right, and provable?
Tell us what you're building, and we'll tell you honestly how we'd approach it.