Proven, not promised

Financial software makes claims that are cheap to state and expensive to verify. Every vendor says the ledger balances, the approvals cannot be bypassed, the bank file is well-formed. The question a buyer should ask is not whether the claims are made but how they are checked — and how often, and against what.

Our answer is specific. Every feature of SQF ships with automated end-to-end tests that run against the real system: a real database, real messaging between services, real bank-format files parsed to the byte. Not simulations of these things. Not mocks. The tests exercise the same code paths, the same infrastructure and the same failure modes that production will, and they run after every change.

The migration that made the rule

The no-mocks rule has an origin, and we tell it plainly because it is the best argument for the rule. Early in the platform's history, a suite of mocked tests passed — comprehensively, green across the board — while a production database migration failed. The mocks had faithfully verified the code's conversation with an imaginary database that behaved the way the code expected. The real database did not.

The lesson we took was not "write better mocks". It was that a mock is a statement of what you believe the world does, and testing your code against your own beliefs is circular. The failures that matter in financial software live precisely in the gap between belief and reality: a driver's actual behaviour, a message broker's delivery semantics, a bank file's real formatting. So the rule became absolute: tests run against real infrastructure or they do not count.

What 395 checks actually cover

Numbers deserve their breakdown, so here is ours. Across the ten finance test suites alone, 395 automated end-to-end checks run against the live system.

The ledger and payments core carries 41 checks, including the full maker-checker chain: a payment prepared by one person, approved by another, refused when the same person attempts both. Payment hardening carries 44, covering multi-approver thresholds — larger payments demanding more signatures — bank acknowledgement handling, and the batching of payments into a single bank file that still settles per payment. Funding pools carry 58, including the complete withdrawal loop through the approval chain: an investor's money leaving through the same four-eyes controls as any other payment. Foreign exchange carries 71, including a live pull from the European Central Bank's published rate feed — the test calls the real feed, not a recording of it. Treasury, collections, credit notes, bank statements, loans and billing carry a further 181 between them.

Each check asserts a specific behaviour: an exact ledger balance after a settlement, a refusal with the correct reason, an acknowledgement that reopens a request without posting a cent. The count grows with the platform, because a feature without its checks does not ship.

The tests are the sales deck

Here is what this buys a customer, stated concretely. Every worked example we show a prospect — the RM 8,000 advance that writes two balancing entries, the payment refused because the preparer tried to approve it, the statement rejected because its lines did not sum to its closing balance — is asserted by a test that runs after every change to the platform.

The examples in our material are not illustrations drawn once and trusted forever. They are living assertions. If a future change broke the four-eyes control, or let an unbalanced entry through, or mishandled a bank rejection, the build would fail before the change reached anyone — not in a quarterly audit, not in a customer's production incident, but on the day the mistake was made, on our machines, at our cost.

What we do not claim

Honesty about testing requires honesty about its limits. End-to-end tests against real infrastructure catch the failures that mocked tests structurally cannot, but no test suite proves the absence of all defects, and we do not pretend otherwise. Our go-live hardening roadmap — transport security, breached-password screening, login anomaly detection — is stated openly rather than waved away, because a buyer's security team will find the gaps anyway and should hear them from us first.

What we claim is narrower and stronger: the controls we describe are continuously demonstrated, not periodically audited. The distinction matters. An audited control was verified at a point in time; a tested control is verified every time the software changes, which is when controls actually break.

Why this discipline is rare

Testing against real infrastructure is slower to build and more demanding to maintain than mocking, which is why it is uncommon. Every suite must create its own test data, drive the real system through real interfaces, assert exact outcomes, and clean up after itself without disturbing anything else. When a test fails, someone must determine whether the software broke or the world shifted — work that mocked tests conveniently avoid by excluding the world.

We pay that cost deliberately, because the alternative is paying it later with interest, in production, with a customer's money in flight. A lending platform's core promise is that the numbers are right and the controls hold. We do not see how to make that promise credibly from behind a wall of mocks — so we make it from test output instead. Proven, not promised, is not a slogan we chose for the sound of it. It is the operating rule the platform is built under, and the standard we invite any prospective customer to hold us to.