Taking a Regulated EU Fintech Platform From 'Looks Live' to Actually Production-Ready
A production-readiness audit is the difference between a platform that looks live and one that actually holds up with money and data on the line. An EU-based fintech company ran a platform that processes payments, payouts and refunds for its users. It deployed cleanly and passed its checks, yet underneath it carried silent defects in exactly the flows that matter most in finance: money movement, data access, and the integrity of the database itself. Valletta.Rescue ran an engineering-grade audit, found the breaks that no demo would reveal, and remediated them to a verified production-live state. For confidentiality we describe the engagement without naming the company or the people involved.
Key Takeaways
- A refund-after-payout edge case was leaking money silently, with no error and no log; closed and tested.
- The database migration history reported a state that did not match the real schema; reconciled and verified object by object.
- A public-read data leak exposed sensitive financial fields to anonymous users; closed on production.
- The platform went from green in CI to verified production-live, with end-to-end tests covering the money and data flows.
The client is an EU-based fintech company running a platform that processes payments, payouts and refunds for its users. The platform compiled, deployed, and returned healthy HTTP responses. By every surface signal it was working. The thesis of the whole engagement was that those signals are not enough: passing CI and returning 200 is not the same as working, and in a money-handling system the gap between the two is where real losses hide.
The Challenge: Green in a Demo, Broken in Production
For confidentiality we describe the engagement without naming the company or the people involved. The dangerous class of defect in fintech is the invisible one. This platform worked in a demo and returned healthy responses, which is precisely why its failures had survived for so long: nothing looked wrong. A silent refund-reversal gap means real funds leave the system unnoticed. A permissive read policy means sensitive financial data is exposed to people who should never see it. A migration history that disagrees with the live database means nobody can fully trust what is actually deployed.
None of these would fail a build or trip an alert. They sit underneath a green status, doing the wrong thing quietly. For a regulated platform that moves money, that is the worst place for a defect to live, because the first time you notice it may be when funds, data, or trust are already gone.
- Silent financial loss: a refund arriving after a payout had transferred was recorded but never reversed.
- A data-access leak: sensitive financial fields were readable by unauthenticated users in production.
- Database-state drift: the migration tracker claimed the latest version while key objects it claimed to have created never existed.
- Dead and data-losing flows: a main listing surface returned empty, key forms silently discarded user submissions, and a core action failed for every user because of a missing access policy.
- Hidden type-safety erosion: hundreds of type-suppression casts masked dozens of real errors, including a live production bug.
The Approach: An Engineering-Grade Audit, Then Remediation
We treated the audit as engineering work grounded in the codebase, not a checklist run from the outside. Every finding was traced to a concrete behavior in the running system and verified against the code, rather than assumed from a symptom. That is what separates a production-readiness audit from a surface scan: the goal is to prove what the system actually does, especially where it does it silently.
Remediation then ran in priority order, money and data first, with each fix backed by a test rather than a manual spot-check, so a closed gap could not quietly reopen. EU data residency and the EU General Data Protection Regulation were treated as design constraints throughout, because the audience and the data are both European fintech. The running product stayed alive for its users while the core was repaired underneath it.
The work was tracked across repeated audit passes, a cadence of incremental delta audits, so progress was provable rather than asserted. Each pass measured what had been closed and what remained, which kept the engagement honest and gave the client a clear, evidence-backed view of how close the platform really was to production-ready.
The Solution: Close the Silent Failures, Then Prove They Stay Closed
- Stopped the silent money loss. Implemented and tested a refund-clawback path that reverses the correct net amount when a refund lands after a payout has already transferred, with idempotency so it cannot double-reverse.
- Reconciled the database with reality. Diffed the live schema against a known-good environment, replayed the missing objects idempotently, and confirmed the production and staging schemas match object by object. The rule that came out of it: a version number is not proof that objects exist.
- Closed the data leak. Replaced the permissive public-read access with a scoped policy and a safe public view, so sensitive financial fields are no longer reachable by anonymous users; verified on production.
- Fixed the dead and data-losing surfaces. The empty listing, the discarded form submissions, the missing detail page, and the action that failed for every user were each made to work and covered by tests.
- Restored type safety and added a regression net. Removed the bulk of the type-suppression casts, fixed the real errors they were hiding, and put end-to-end tests plus CI coverage floors in place so these regressions cannot return silently.
Because this is a regulated EU fintech platform handling financial data, data protection shaped the remediation:
- EU-resident, access-controlled data with audit logging.
- Access scoped by role, with sensitive fields no longer exposed.
- No customer financial data routed through public AI services or third-party training pipelines.
It passed CI and returned 200. Making it actually hold up in production, with money and data on the line, was the real job.
The Results: Verified Production-Live
The platform moved from green in CI to verified production-live. The failures that mattered most are closed, and they are closed in a way that can be demonstrated rather than assumed, because each one is now covered by a test.
- The refund-after-payout money leak is closed and tested.
- The production database is reconciled and matches staging object by object.
- The data leak is closed on production.
- The dead and data-losing flows work and are covered end to end.
- The platform is production-live, with the critical money and data paths under automated tests and CI guarding against regression.
To be measured about it, the remaining gates at handover were external inputs, third-party keys and legal sign-off, not engineering defects. The engineering work that made the platform safe to run with real money and real data was done and verified. For more engagements like this, browse our success stories.
Frequently Asked Questions
What does a production-readiness audit actually find that CI does not?
Silent failures: flows that return healthy responses while doing the wrong thing, like money that leaves on a refund without being reversed, or data readable by users who should not see it.
How do you audit a fintech platform without touching live customer data?
Findings are traced to behavior in code and verified against a known-good environment. Sensitive data stays EU-resident, access-controlled and minimized.
Can you both audit and fix, or only report?
Both. Valletta.Rescue audits, then remediates in priority order, money and data first, with each fix backed by a test rather than a manual check.
Shipping Fast With AI-Generated Code?
When a platform compiles, deploys and returns 200, it is easy to assume it works. A Valletta.Rescue audit finds the silent failures, the money that leaves without being reversed, the data readable by the wrong people, the database that disagrees with itself, before they cost you money or trust. See how it works on our Vibe-Coding audit page.
Get a free consultation: vallettasoftware.com/contact