Finance infrastructure is a platform discipline. I design and build the systems that keep finance teams operating at scale -- settlement, reconciliation, account management, and analytics -- treating each as a governed, reusable primitive, not a one-off tool.
By the numbers
About
I lead Finance Systems at Moniepoint across two teams -- an internal platform team responsible for settlement, reconciliation, and account management systems, and an external systems team covering ERP, procurement automation, and FP&A tooling.
My core conviction is that finance infrastructure should be treated as platform infrastructure -- composable, reusable, and governed -- rather than a collection of bespoke tools built to spec. Every system I design starts with that constraint: what is the primitive, who owns it, and how does the rest of the estate consume it without negotiating each time?
Before this, I worked in strategy and analytics at gomoney. I write under the identity The Pretender -- thinking out loud about finance systems, platform design, and the craft of building infrastructure that lasts.
Settlement and reconciliation capability documentation, multi-entity migration analysis, and IFRS 9 expected credit loss modelling across unreconciled accounts.
Platform philosophy
"The goal is never the tool. It is the primitive -- the smallest unit of shared behaviour that every downstream system can compose without negotiating with you each time. Build the primitive right, and the ecosystem builds itself."
Latest writing
Settlement
Net-to-zero as a universal primitive in settlement systemssoon
Why every settlement workflow reduces to the same underlying invariant, and how to build around it.
Coming soon
Platform thinking
Why finance systems belong in platform teamssoon
The case for treating internal finance infrastructure with the same rigour as external-facing products.
Coming soon
Platform work
Finance Systems is a platform organisation -- not a tools team. Each domain is a bounded capability with a defined owner, a governed data model, and a stable interface to the rest of the estate.
Settlement
Internal platform
Responsible for the movement and confirmation of funds across all payment instruments and counterparty types. The platform enforces a single architectural invariant at the system level: every settlement cycle must reduce to a net-zero state. This is not left to individual workflow implementations -- it is a constraint the platform upholds unconditionally.
Building around this invariant changes the design of everything downstream. Exception handling, retry logic, and reporting all become simpler when the system has a clear, enforceable definition of what "settled" means. The settlement platform owns that definition and exposes it as a primitive that other systems can depend on.
Reconciliation
Internal platform
Reconciliation is decomposed into three distinct sub-capabilities, each with separate ownership: the ledger-side account view (what the books say), automated assurance (matching what moved against what was expected and surfacing exceptions), and a human-in-the-loop control layer for payment vetting and final sign-off.
Keeping these three sub-capabilities separate is a deliberate architectural choice. In monolithic reconciliation systems, an exception in one area cascades silently into the others -- the ledger view diverges, assurance runs against dirty data, and the control layer operates blind. Decomposing them gives each sub-capability a clean failure mode and a clear owner.
Account and Ledger Management
Internal platform
The source of truth for account structure across all legal entities. It owns the chart of accounts, account lifecycle management (creation, classification, closure), and transaction aggregation. The data architecture separates transactional state from analytical consumption: operational writes land in a relational store; downstream analytical workloads consume from a columnar warehouse.
This separation is a foundational primitiveprimitiveThe smallest unit of behaviour a system exposes that others can build on without knowing how it works inside.See glossary → -- it prevents analytical query load from degrading transactional performance and gives downstream systems a stable, observableobservableA system is observable when you can tell what state it is in from the outside -- without guessing or digging through logs.See glossary → interface that does not change when the operational schema evolves.
Finance Analytics
Internal platform
A natural-language query interface over the finance data estate. Finance teams ask questions in plain language and receive answers backed by governedgovernedSubject to defined rules, owners, and review processes -- so changes are deliberate and their impact is understood.See glossary →, versioned data definitions -- without writing SQL or depending on a data team as an intermediary.
The foundation is a structured semantic layersemantic layerA translation layer that maps raw database tables into named, defined business concepts -- so "revenue" means the same thing everywhere it is used.See glossary → where every metric definition, join logic, business rule, and system characteristic is versioned and owned. Each definition is a discrete unit of finance knowledge with a canonical identifier -- queryable by the AI agent at request time rather than embedded statically at build time. This makes the semantic layer evolvable without redeploying the interface.
ERP, Procurement and FP&A
External systems
Multi-entity ERP implementation covering IFRS-compliant financial reporting, consolidated ledger management, audit remediation, and user access governance across eight legal entities in Nigeria and the UK. The ERP is the external reporting and statutory compliance layer -- not a replacement for internal platform capability.
The integration posture between internal and external systems is deliberate: the internal platforms own the operational source of truth; the external layer consumes from them via defined integrations. Procurement automation and AI-native FP&A tooling sit alongside the ERP, each scoped to its domain.
Open framework
A framework for getting finance data into a structured, governedgovernedSubject to defined rules, owners, and review processes -- so changes are deliberate and their impact is understood.See glossary → format that AI systems and analytics tools can reliably consume.
Finance teams sit on large amounts of data but struggle to make it consistently queryable -- not because the data is missing, but because the definitions are not written down, are disputed across teams, or live only in someone's head. The Cones framework solves this by giving finance organisations a lightweight structure for capturing and versioning financial knowledge.
Cone type
Metric definition
A versioned, canonical definition of a finance metric -- what it measures, how it is calculated, what it excludes, and who owns it.
Cone type
Join logic
A documented, governed rule for how two finance data entities relate -- the keys, the cardinality, and the conditions under which the join holds.
Cone type
Business rule
A codified finance policy or constraint -- the kind of rule that is usually tribal knowledge, now made explicit and version-controlled.
Cone type
SQL example
A curated, reviewed query that demonstrates how to correctly answer a class of finance question -- reusable and attributable.
Cone type
System characteristic
A documented property of a finance system -- its latency, its refresh cadence, its known gaps -- so downstream consumers know what they are building on.
Each Cone is a discrete, structured unit of finance knowledge with a canonical identifier, a type, and a version. The full specification, schema, and implementation guide will be published here. If you are building finance analytics infrastructure and want to use or contribute to the framework, get in touch.
How I build
Every system should expose the smallest reusable unit of behaviour. A feature that cannot be composedcomposableDesigned so that smaller parts can be combined freely to build bigger things, without each combination requiring custom work.See glossary → by another system is a dead end. The net-zero settlement invariantinvariantA condition that must always be true, no matter what. The system enforces it -- individual workflows don't get to override it.See glossary →, classification rules enforced at account creation -- these are primitivesprimitiveThe smallest unit of behaviour a system exposes that others can build on without knowing how it works inside.See glossary →, not features.
Each platform owns its data model and is the single source of truth for that domain. Downstream systems consume via defined interfaces -- they do not bypass the platform to query the underlying store directly.
External tools are right for their domains. But core financial integrity -- settlement, reconciliation, account structure -- requires internal ownership. You cannot outsource the invariantsinvariantA condition that must always be true, no matter what. The system enforces it -- individual workflows don't get to override it.See glossary → that define your financial trustworthiness.
A reconciliation system that cannot tell you its own state is not a system -- it is a process. Every platform has defined KPIs, owned outcomes, and a clear answer to: what does healthy look like, and who knows first when it is not? That is what observabilityobservabilityA system is observable when you can tell what state it is in from the outside -- without guessing or digging through logs.See glossary → means in practice.
The Pretender
Thinking out loud about settlement, reconciliation, platform design, and the craft of building financial infrastructure at scale. Honest about what is hard.
Settlement and reconciliation
Settlement
Net-to-zero as a universal primitive in settlement systemssoon
Why every settlement workflow reduces to the same underlying invariant, and how designing around it changes everything downstream.
Coming soon
Reconciliation
Why reconciliation needs three owners, not onesoon
The ledger view, automated assurance, and the human control layer are not phases of the same process -- they are distinct capabilities with distinct failure modes.
Coming soon
Data
IFRS 9 ECL on unreconciled accounts: methodology and lessonssoon
What building an expected credit loss model over a large population of unreconciled accounts taught me about the gap between accounting standards and engineering reality.
Coming soon
Platform thinking
Platform thinking
Why finance systems belong in platform teamssoon
The case for treating internal finance infrastructure with the same rigour -- roadmaps, APIs, SLAs -- as external-facing products.
Coming soon
Platform thinking
The Cones framework: a semantic layer for finance datasoon
How I designed the Cones framework to give finance teams a structured, versioned way to capture metric definitions, join logic, business rules, and system characteristics -- and make all of it queryable at runtime.
Coming soon
Engineering
Columnar databases for finance workloads: patterns that mattersoon
The query patterns and optimisation techniques that separate fast from slow when your finance tables measure in the hundreds of millions of rows.
Coming soon
Finance operations
Finance operations
Cost centre design across multiple legal entitiessoon
The tradeoffs in designing a cost centre hierarchy that works across entities, currencies, and reporting requirements -- and how to structure the decision.
Coming soon
Finance operations
Capacity planning for platform migrations: the lever problemsoon
When a migration represents net-new load, someone has to name the levers. Timeline, scope, or headcount -- you cannot have all three.
Coming soon
Glossary
These are terms from computer science, systems design, and platform engineering that appear throughout this site. Each entry gives a plain-English explanation first, then the more precise technical meaning for those who want it.
A rule the system must never break, no matter what happens. Not a guideline -- a hard guarantee.
A condition that holds true before and after every operation in a system, regardless of input or sequence. In settlement systems, the net-to-zero invariant means every cycle must balance -- debits equal credits -- and the platform enforces this at the system level, not within individual workflows. The term comes from mathematics (properties preserved under transformation) and was formalised in software by Dijkstra and Hoare's work on program correctness in the 1960s-70s.
Origin: mathematics, formal methods, distributed systems literature
The smallest building block a system exposes. Other systems use it directly without needing to understand how it works inside.
In computing, primitives are the fundamental operations or data types from which more complex behaviour is composed. In platform engineering, a primitive is a unit of functionality that is stable, well-defined, and composable -- meaning other teams can depend on it and build on top of it without coordinating with the team that owns it. Popularised in API-first thinking by Stripe and AWS, who describe their APIs as primitives developers combine to build products.
Origin: computer science, API-first platform design (Stripe, AWS)
Designed so that independent parts can be combined freely to build larger things -- without each combination needing custom wiring.
A system is composable when its components have clean interfaces and no hidden dependencies, allowing them to be assembled in new combinations without modification. In finance infrastructure, composability means a settlement primitive, an account management primitive, and a reconciliation primitive can be combined into new workflows without each requiring bespoke integration work. Related to the Unix philosophy: small tools that do one thing well and connect via standard interfaces.
Origin: functional programming, Unix philosophy, Gartner composable enterprise (2020)
A team that builds shared internal tools and services so that other teams don't each have to solve the same infrastructure problems from scratch.
Defined in Team Topologies (Skelton & Pais, 2019) as a team that provides a compelling internal service -- a platform -- that reduces the cognitive load of stream-aligned teams. A platform team is not a service desk; it treats other internal teams as customers and builds self-service capability they can consume without raising tickets. The distinction between a platform team and a tools team is that the platform team owns outcomes across the estate, not just delivery of individual requests.
Origin: Team Topologies (Skelton & Pais, 2019)
The property of a system that lets you understand what it is doing -- and why -- from the outside, without having to guess or dig through its internals.
Borrowed from control theory, where a system is observable if its internal state can be inferred from its outputs. In software, popularised by the site reliability engineering (SRE) discipline: an observable system exposes enough signals (metrics, logs, traces) that operators can diagnose its state without instrumenting new code. In the context of finance platforms, observability means the system can answer "are we reconciled right now?" in real time, without a manual investigation.
Origin: control theory, Google SRE practices, distributed systems engineering
Subject to defined rules, clear ownership, and a review process -- so that changes are intentional and their effects are understood before they happen.
Data governance refers to the policies, roles, and processes that determine who can change data definitions, how changes are approved, and how conflicts between definitions are resolved. A governed semantic layer means each metric definition has an owner, a version history, and a change process -- not just a name in a spreadsheet. Without governance, definitions drift: two teams use the same word for different calculations and neither knows it until the numbers disagree in a board meeting.
Origin: enterprise data governance, DAMA International DMBOK
A translation layer that sits between raw data and the people or systems that use it. It maps database tables into named business concepts so that "revenue" means the same thing everywhere.
Introduced in business intelligence in the 1990s (BusinessObjects, Cognos) as a way to abstract SQL complexity from end users. Revived in the modern data stack era by tools like dbt, Looker, and AtScale. A semantic layer defines metrics, dimensions, and business rules in one place; all queries and reports derive from those definitions. The Cones framework extends this concept to cover not just metric definitions but join logic, business rules, SQL examples, and system characteristics -- the full knowledge surface a finance AI agent needs at runtime.
Origin: business intelligence (1990s), modern data stack (dbt Labs, Looker)
What a system or organisation can do, described independently of how it is done. Capabilities are stable even when the underlying technology changes.
Business capability modelling comes from enterprise architecture (TOGAF, 2009 onwards) and describes what an organisation does in terms of stable outcomes rather than current processes or tools. A capability like "reconciliation" exists whether you do it in spreadsheets or a purpose-built platform -- the capability is what you can do, not how. This stability makes capabilities a useful unit for planning and investment: you assess capability maturity, not tool maturity. On this site the term is used loosely and can be read as "what the system is responsible for."
Origin: TOGAF enterprise architecture framework, business capability modelling
Contact
I am open to conversations about finance systems architecture, platform strategy, and the engineering of financial infrastructure. If you are building something in this space or want to think through a problem, reach out.