Financial Services Software: Development and Product Management
I'm Matt Ratcliffe. Alongside healthcare, financial services is where I have spent most of my career — as a software developer building the systems, and as a product manager responsible for what they should do and when. Financial planning, calculation engines, risk and insurance, superannuation, mortgages, and the commission that flows through all of it.
Both sides of the table
Financial services software has an unusual failure mode: the code can be flawless and the product still wrong, because someone misread a regulation, a product rule or a fee definition. Equally, a perfectly specified product can fail because nobody asked whether the calculation could be reproduced two years later when a client disputes it.
Having worked as both a product manager and a developer in this domain, I tend to be useful precisely at that seam. I can sit in a room with compliance, an actuary or a product owner and come out with something an engineering team can actually build — and I can then go and build it. In a domain where the specification is the hard part, that combination saves a great deal of translation loss.
Where I have worked in this space
Financial planning
Advice platforms and the tooling around them — client data, goals, projections, modelling, and the documents that come out the other end, including statements of advice and ongoing fee arrangements.
What makes it hard: The advice process is heavily prescribed, and the software has to leave an evidentiary trail. What was recommended, on what basis, using which assumptions, and what the client was shown at the time all need to be reconstructable years later.
Calculation engines
Projections, contributions, drawdowns, tax treatment, premiums, fees and the modelling that sits behind advice and product illustrations.
What makes it hard: Determinism and versioning. Rules change on fixed dates, so an engine needs effective-dated rule sets and has to reproduce a historical result exactly rather than recalculating it with today's parameters.
Risk and insurance
Life, TPD, trauma and income protection — quoting, underwriting rules, policy administration, and cover held both inside and outside superannuation.
What makes it hard: Underwriting is a large, changing rule set that product owners need to control without a code release, and cover inside super adds a second set of constraints on top of the insurance ones.
Superannuation
Member administration, contributions and caps, preservation, rollovers, investment switching, insurance within super, and the reporting that goes with it.
What makes it hard: The rules are intricate, interact with tax, and change on a fixed annual cycle. Contribution caps, preservation and transfer balance limits all depend on member circumstances and history, so almost nothing can be evaluated from current state alone.
Mortgages and lending
Origination and broking workflows, serviceability and affordability assessment, LVR and insurance thresholds, and the systems supporting brokers and aggregators.
What makes it hard: Responsible lending obligations mean the assessment has to be defensible, not just calculated — with the inputs, buffers and policy version that produced a decision retained alongside it.
Commission tracking & distribution
Upfront and trail commission, splits across licensee, practice and adviser or broker, clawbacks, adjustments, and reconciliation against payer statements.
What makes it hard: It is a reconciliation problem wearing an arithmetic costume. Expected versus received, hierarchical splits, and clawbacks that have to unwind cleanly through every split they originally touched — months after the fact.
Calculations are the product
In most financial services systems the calculation is not a feature — it is the thing being sold. A projection, a premium, a serviceability assessment or a commission statement is the output the customer, adviser or regulator actually sees, and everything else is packaging around it.
That has consequences most general-purpose software never has to think about. Calculations have to be deterministic and reproducible long after the fact, which means the rules that produced a number have to be versioned with effective dates and stored alongside the result — not simply replaced when they change. When a client complains about a figure from three years ago, "we recalculated it with today's rules and got a different answer" is not an acceptable response.
Money itself needs handling with more care than it usually gets: no floating point, explicit rounding rules applied at defined points, and a deliberate decision about who receives the remainder when an amount is split. Rounding that is merely incidental produces reconciliation differences that grow quietly until somebody has to explain them.
Commission is a reconciliation problem
Commission tracking and distribution deserves particular mention, because it is consistently underestimated. On the surface it is arithmetic. In practice it is a reconciliation problem with a hierarchy attached: expected versus received, upfront versus trail, splits between licensee, practice and adviser or broker, and clawbacks that reverse payments made months earlier and have to unwind cleanly through every split they touched.
The systems that work are the ones that treat every payment as a fact to be matched rather than a number to be stored, and that can always answer why a particular person was paid a particular amount at a particular time. The ones that fail are the ones where the spreadsheet somebody maintains alongside the system is the real source of truth.
Regulatory change is a delivery constraint
In this domain, deadlines arrive from outside and do not move. Superannuation thresholds change on 1 July. Reporting obligations begin on the date the regulator says. A team that treats regulatory work as ordinary backlog will eventually meet a date it cannot miss without having planned for it.
Handling that well is mostly a product management problem: knowing what is coming, understanding what it actually requires, and building systems where a rate, threshold or rule change is configuration with an effective date rather than a code release. The architectural decision and the compliance calendar are the same conversation.
Security and data obligations
Financial services systems hold exactly the data that attracts both regulators and attackers: identity documents, tax file numbers, account and payment details, and complete financial positions. Everything I have written about high-risk data systems applies here, with the addition of sector-specific obligations — APRA's CPS 234 for regulated entities, PCI DSS wherever card data is involved, and the access controls that keep an adviser to their own book of clients.
AI features in this setting need the same care and then some. There is a hard line between summarising or drafting to assist a human and producing something that constitutes personal financial advice, and it is a line worth designing around deliberately rather than discovering later.
How I engage
Development, product management, or the combination — specifying a calculation engine and then building it, taking a regulatory change from announcement to shipped, or reviewing a system somebody else built before you commit to extending it. Engagement models are on the freelance engagements page.
To be clear about scope: I build the software. I am not a licensed adviser and I do not provide financial product advice or compliance sign-off — those sit with your licensee, compliance function and legal advisers. What I bring is someone who can read the rule, understand what it means for the system, and implement it correctly.
Common questions
Do you work as a developer, a product manager, or both?
Both, and the mix depends on what is missing. Some engagements are pure delivery against a specification somebody else owns. Others start earlier — working out what a regulatory change or product idea actually requires, writing that down in a form a team can build, and then building it. In this domain the specification is usually the hard part, so being able to do both tends to remove a lot of translation loss.
Can you build a calculation engine we can audit?
That is the only kind worth building. In practice it means effective-dated rule sets rather than rules edited in place, storing the rule version alongside every result, deterministic outputs for identical inputs, and the ability to re-run a historical calculation and get precisely the number the client was originally shown. If an engine cannot do that, its first serious complaint will be very expensive.
How do you handle rates and thresholds that change every year?
As configuration with effective dates, owned by the people who understand the rules, rather than constants in code that need a release. The system should be able to hold next year's values before they take effect and apply them on the right date automatically — and just as importantly, keep applying last year's values to last year's transactions.
Our commission reconciliation is a spreadsheet. Can that be fixed?
Usually, and the spreadsheet is worth understanding before replacing it — it generally encodes real business rules nobody wrote down. The target is a system where every payment received is matched against what was expected, splits are calculated rather than maintained by hand, clawbacks reverse cleanly through the hierarchy, and any given payment can be explained. That is achievable; it is mostly a matter of modelling payments as facts to be matched rather than balances to be updated.
Do you provide financial advice or compliance sign-off?
No. I build software. Licensing, advice and compliance sign-off sit with your licensee, compliance function and legal advisers. What I bring is the ability to read an obligation or product rule, work out what it means for the system, and implement it correctly — which is a different job from being the person who certifies it.
What about AI in financial services software?
Useful for summarisation, drafting, extraction and internal search; genuinely risky wherever output could be read as personal financial advice. The design work is in drawing that boundary deliberately, keeping a human accountable for anything client-facing, and making sure retrieval respects who is allowed to see which client. I have written more about that on the AI page.
Building or fixing something in this space? Tell me what it has to calculate — or see high-risk data systems and my full resume.