Fintech engineering teams in Sydney and Melbourne are under a different set of rules than most software shops. Shipping working code is the easy part. Proving that the code was reviewed, tested and approved by the right person before it touched production is the part that eats a sprint. Claude Code does not remove that obligation, but it changes what the evidence looks like and how much it costs to produce.
The audit problem most fintech teams inherit
Ask an engineering lead at an Australian payments company or neobank what happens before a release goes to APRA-regulated production, and you will hear some version of the same story. A change gets written, a pull request gets opened, someone approves it, a deploy pipeline runs, and then, weeks or months later, an internal audit or an APRA prudential review asks for evidence: who wrote this, who reviewed it, what tests ran, and whether a compliance officer signed off before it touched customer money.
Most teams reconstruct that evidence after the fact. Someone digs through GitHub, Slack and a spreadsheet to rebuild a timeline that should have existed automatically. That reconstruction work is where the real cost sits, and it rarely shows up on a project plan.
Who authored the change and what prompted it (a ticket, an incident, a regulatory requirement).
Who reviewed it, what they checked, and whether the review happened before or after deployment.
What automated tests and security scans ran, and whether any were skipped.
Who approved the release for a CPS 234-relevant system, and on what date.
Whether the change touched customer data covered by the Privacy Act 1988.
What changes when Claude Code writes the first draft
Claude Code works from a plan, executes it in a visible session, and produces a commit history and a written record of what changed and why, as a normal side effect of doing the work. That record is not a compliance add-on bolted on afterwards; it exists because that is how the tool operates. For an audit-ready workflow, that is the useful part.
A worked example: a payments reconciliation service
A Sydney-based payments client asked Claude Code to add a new reconciliation rule to a nightly settlement job. The session started with a plan describing the affected files, the risk of double-counting a transaction type, and the tests it intended to add. A senior engineer reviewed the plan before any code was written, not just the final diff. The commit that followed referenced the ticket number, the plan, and the specific tests added to cover the edge case. None of that required a separate compliance tool. It was the ordinary output of the session, captured because someone asked Claude Code to work in plan mode against a real ticket instead of freeform.
Building a review workflow that holds up under an APRA review
None of this replaces human accountability. APRA's CPS 234 standard and ASIC's expectations around operational resilience still require a named person to own the review and approval of changes to critical systems. What Claude Code changes is how cheap it is to produce the evidence that a human did that job properly.
Require plan mode for any change touching a CPS 234-in-scope system, and store the plan alongside the ticket.
Have a named reviewer approve the plan before implementation starts, not only the final pull request.
Keep the full session transcript as an artefact linked to the deployment record, not just the diff.
Tag commits with the ticket, the reviewer, and the test coverage added, so a search finds the evidence in seconds.
Run a quarterly sample audit against a handful of changes to confirm the trail actually holds up.
What this is worth to a Sydney fintech engineering team
A mid-sized fintech engineering team of around a dozen people spends real money on audit preparation every year, between engineer time reconstructing evidence and the external cost of an audit that takes longer because records are incomplete. Teams we have worked with put that reconstruction cost somewhere between $40,000 and $65,000 a year once you count the senior engineering hours involved. Capturing the evidence as a byproduct of the Claude Code workflow, rather than rebuilding it after the fact, is the difference between an audit that takes a week and one that takes a month. On a $120,000 external audit engagement, cutting the preparation time in half is not a rounding error.
Where to start
Start with one CPS 234-in-scope system and one team. Turn on plan mode as a requirement for changes to that system, wire the session transcript into your existing change record, and see what your next internal audit sample actually finds. Most Australian fintech teams that try this on a single service extend it everywhere within a quarter, because the alternative is going back to manual reconstruction.
If you want help mapping this against your own APRA or ASIC obligations, get in touch for a working session at /contact and we will look at your current release process together.
