Banking · payments · insurance · superannuation · fintech

SQL Server support for finance systems

Core banking, payments, ledgers and settlement run on databases where the recovery point objective is not a preference and the auditor is not optional. Specialist SQL Server cover from Australian consultants, with the access terms written into the agreement.

Free 20-point health check Call 1800 431 416

Finance systems are the case where "we have backups" is not an answer. A ledger, a payments switch or a settlement system has a recovery point objective expressed in minutes or seconds, and somebody outside the organisation is entitled to ask you to demonstrate that the configuration can actually deliver it.

That is a different standard from most database work. It is not enough for the backups to run; the restore has to have been performed, the failover has to have been rehearsed, and the gap between the recovery objective written in the policy and the one the configuration can meet has to be either zero or documented.

In our experience that gap is the single most common finding in this sector — not because teams are careless, but because testing it properly has always required an outage nobody could justify scheduling.

Where we are usually brought in

What finance estates ask us for

Availability and evidence, in roughly that order — with performance a distant third until settlement starts running late.

Recovery objectives you can evidence

Not what the policy says, but what the configuration can actually deliver — measured, documented, and with the difference between the two stated plainly rather than smoothed over.

High availability that has been tested

Always On availability groups and failover clustering, designed and built — and then failed over on purpose, which is the part most estates skip until the night it matters.

A DR site that can carry production

A recovery environment sized as insurance rather than as production delivers a service too slow to use. Sizing it against the real workload, at matching patch levels, with the cutover rehearsed.

Encryption across data and backups

Transparent Data Encryption applied across the data files and the backups together, with key management documented — because a restored copy on a test server is part of the estate too.

Access that survives an audit

Named accounts rather than shared credentials, least privilege, logged sessions, and a current access list you can produce on request rather than reconstruct.

Settlement and batch windows

Overnight batch that has grown past its window, where the question is whether to tune it, reshape it or move the reporting load off the instance entirely.

What you have to be able to evidence

The obligations that shape a finance database

Which of these apply depends on what you are and what you process. The common thread is that each one asks for evidence rather than intent.

APRA CPS 234 applies to APRA-regulated entities and requires information security capability, controls over information assets managed by third parties, and systematic testing of those controls — including the ability to demonstrate it
Where cardholder data is in scope, PCI DSS carries its own requirements for encryption, access control, logging and the separation of duties
The Privacy Act and the Notifiable Data Breaches scheme require you to establish what was accessed, by whom and when — which depends on logging decided long before the incident
The ACSC Essential Eight expects vendor-supported, patched software, which is the control an ageing SQL Server version quietly fails
Business continuity obligations ask for a tested recovery, not a documented intention to recover — the distinction is the one auditors press on
Third-party and supply-chain reviews increasingly ask who holds database credentials and in which country they sit, in writing

Getting started

Replacing an assumed recovery objective with a measured one

The first engagement in this sector is almost always about recoverability, because that is the finding that cannot wait.

Establish what the configuration can deliver

Backup chains, log shipping intervals, replication lag and failover behaviour, measured rather than read off a policy document. The free 20-point health check covers this on one instance.

Compare it against what you have committed to

The recovery point and recovery time objectives in your policy, against the ones the estate can actually meet. Where there is a gap, it is stated in writing with what it would take to close it.

Test the failover on purpose

A rehearsed failover and a documented procedure that can be run without interrupting production — so a DR test stops being an outage nobody will schedule.

Then run it under an SLA

24/7 monitoring with alerts routed to an on-call Australian DBA, a guaranteed response time from one hour, and a monthly report your risk function can file rather than interpret.

Can you evidence your recovery objective?

The free 20-point health check measures what the configuration can actually deliver on one instance, read-only, with a written report you can hand to your risk function — whether or not you engage us.

Book the free health check

Published 9 October 2026

FAQ

Common questions

Yes, and it is the default rather than an upgrade. Database work is Australian-only: every login to a client database instance is made by an Onsys DBA based in Australia, and no offshore engineer holds credentials to a client database on any plan. We will tell you which engineers hold access before you sign, and the access terms go into the agreement rather than living on a web page.

Yes. We provide the current access list on request at any point in the engagement, every session against your environment is logged and auditable, and changes carry a documented before-and-after. Where your reviewers want the access terms contractually committed rather than asserted, raise it during scoping and it is written in. We are a service provider, not your assurance function — we supply the evidence, your team makes the attestation.

Depending on the configuration, by failing over to a replica or by bringing a recovery copy up in isolation while production stays open to applications. We have built exactly this for clients whose DR plan existed on paper because testing it meant an outage that kept being postponed. The deliverable is a written procedure your team can run again without us.

Yes. Plan C covers mixed estates across SQL Server, PostgreSQL and Oracle, and we also support MySQL, MariaDB, MongoDB and EDB Postgres, on-premises and on Azure, AWS and Oracle Cloud Infrastructure. Mixed finance estates are the normal case rather than the exception.

Plan B is $3,000 per month excluding GST with a one-hour response SLA at any hour and 20 professional service hours, which is where most finance estates sit. Plan C is $7,500 for larger mixed-platform estates with 50 hours. Project work — high availability builds, DR rebuilds, migrations — is quoted as a fixed price after the assessment.