Most finance apps are built on top of infrastructure someone else owns. That is a reasonable place to start and a difficult place to stay. When market data, accounts, and the connections between them belong to third parties, so do your worst outages and your hardest limits. FinanceCore is the backbone we built so that the parts we most depend on are parts we control.
Why we built it
The decision came from a simple observation. Every application we run needs the same handful of things: a reliable stream of market prices, a trustworthy record of accounts and balances, and secure ways for services to talk to each other. Rebuilding those separately inside each product would have meant three fragile versions of the same critical machinery, each drifting out of step with the others.
FinanceCore is the alternative. One financial core, built once, built well, and shared. Tradvex reads prices from it. High Risk Evaluations pulls the data it grades from it. New products start with the hard part already solved. Consolidating the plumbing also consolidated the responsibility: one place to make correct, one place to secure, one place to keep running.
The pieces
FinanceCore is not a single program. It is a small set of services, each with one job.
Market data
Prices are the raw material of everything we do, and prices are messy. Feeds disconnect, print bad ticks, and disagree with one another. The market data service ingests external feeds, cleans them, reconciles the disagreements, and publishes a single stream the rest of the system can rely on. Downstream, a signal or a risk grade is only as trustworthy as the price it was built from, so this is where a great deal of unglamorous care goes.
Accounts
The accounts service is the system of record: who exists, what they hold, what they are entitled to, what changed and when. Financial records have a property ordinary application data does not. They have to be auditable. Every balance must be explainable by the sequence of events that produced it. So we treat account changes as an append only history rather than a value that is quietly overwritten, which means the answer to how did this get here is always recoverable.
Secure APIs
The services are useless in isolation; the value is in how they connect. Every connection between them, and every connection a product makes to the core, runs through authenticated, permissioned interfaces. A service can reach only what its job requires and nothing more. There is no informal back door, no shared master key passed around for convenience. The APIs are the front door, and the front door is the only door.
Reliability choices
Infrastructure earns trust by being dependable on the days it would be easiest to fail. A few decisions carry most of that weight.
We assume components will fail and design so that one failure is an inconvenience rather than an outage. Critical paths degrade instead of collapsing: if a data feed drops, the system falls back to a known good source rather than going dark. State that matters is persisted, so a restart resumes rather than forgets. And we watch the system continuously, because a failure caught in seconds is a footnote, while the one you hear about from users first is a headline.
Security choices
Financial infrastructure is a target, and the honest posture is to assume attempts rather than hope for their absence.
- Least privilege by default. Every service, key, and person gets the narrowest set of permissions that lets them do their work, and nothing spare.
- Encryption in transit and at rest. Sensitive data is protected on the wire and on disk, not just at the edges.
- Secrets in managed stores. Credentials live in dedicated secret stores, never pasted into code or configuration files.
- Logged actions. Operations against the core are recorded, so that after any incident there is a truthful account of what happened rather than a guess.
None of these are exotic. Security is rarely a clever trick and almost always the ordinary things done without exception.
We do not sell FinanceCore. We run our products on it. The infrastructure has to satisfy its most demanding customer, which is us.
Built for our own products first
FinanceCore has no external customers to impress. That shapes it more than any feature list could.
When the same team builds the infrastructure and depends on it, the incentives line up. A shortcut in the core becomes a bug in Tradvex a week later, felt by the people who took the shortcut. There is no way to declare the platform finished and hand its problems to someone else, because its only users are the next desk over. Building for ourselves first is not modesty. It is the most reliable quality control we know: we are the first to feel anything we get wrong, and the most motivated to fix it.
The products that run on this core, copy trading and risk evaluation, are covered in the two pieces below.