Photo by stockpoint
Disaster recovery restores your remittance systems after a failure; business continuity keeps your business running while you do it. That distinction matters more than it sounds. Disaster recovery (DR) is the technical process of bringing servers, databases, and applications back online after an outage. Business continuity (BC) is the broader operational plan that keeps customer transfers moving, compliance obligations met, and staff functioning even when your primary systems are down.
For an Australian remittance operator, confusing the two creates a dangerous gap. You might rebuild your transaction database in four hours yet still breach AUSTRAC record-keeping requirements because you had no interim process for capturing customer identification during the outage. This guide separates the two disciplines, maps them to your regulatory obligations under the AML/CTF Act 2006, and gives you a practical framework for building IT resilience that survives both a cloud region failure and a Monday-morning payment surge.
Key Takeaways
- Disaster recovery is the technical restoration of systems; business continuity is the operational plan that keeps your MTO running during and after disruption.
- AUSTRAC requires you to retain transaction and identification records for seven years — an outage does not pause that obligation.
- Your Recovery Time Objective (RTO) and Recovery Point Objective (RPO) define how fast you recover and how much data you can afford to lose.
- Real-time replication across cloud availability zones protects against data loss for high-value corridors where transactions cannot be reconstructed.
- Your business continuity plan should include manual fallback procedures for customer identification, TTR and IFTI reporting, and settlement during system downtime.
Disaster Recovery vs Business Continuity: The Core Difference
The two disciplines answer different questions. Disaster recovery asks: how do we get the technology back? Business continuity asks: how do we keep serving customers and meeting obligations until we do?
A remittance platform is a chain of dependencies — payment service provider, core ledger, compliance screening engine, payout network APIs, and customer-facing app. When one link breaks, DR handles the technical repair. BC handles everything else: staff communication, customer notifications, regulatory reporting workarounds, and settlement continuity.
Consider a concrete scenario. Your cloud provider's Sydney availability zone suffers a three-hour outage during peak Friday remittance volume. Disaster recovery is your automated failover to a second zone. Business continuity is the decision tree your operations team follows: pause new high-value transfers, communicate delays to agents, capture pending KYC data manually, and reconcile once systems return.
| Dimension | Disaster Recovery | Business Continuity |
|---|---|---|
| Scope | IT systems and data | Whole business operation |
| Owner | CTO / infrastructure team | COO / risk & compliance |
| Trigger | System or data failure | Any disruption (IT, staff, premises, supplier) |
| Goal | Restore technology | Maintain critical functions |
| Key metric | RTO / RPO | Maximum Tolerable Period of Disruption |
| Example output | Cloud failover, backup restore | Manual KYC process, agent comms plan |
You need both. A flawless DR plan with no BC plan means your systems recover but your team improvises during the outage — and improvisation around AML/CTF obligations is where breaches happen.
Why IT Resilience Is a Regulatory Issue for MTOs
AUSTRAC does not mandate a specific disaster recovery architecture, but resilience underpins several obligations you cannot suspend during an outage.
Record-keeping under the AML/CTF Act. You must retain records of transactions and customer identification for seven years. If an outage corrupts or loses transaction data, you have breached a core obligation regardless of the cause. Your backup and replication strategy directly protects your compliance position.
Reporting timeliness. Threshold Transaction Reports (TTRs) are due within 10 business days, and International Funds Transfer Instructions (IFTIs) within 10 business days of the instruction. A prolonged outage that prevents you from capturing or lodging these reports does not extend the deadline. Your continuity plan must include a mechanism to capture reportable data manually and lodge once systems recover.
Ongoing customer due diligence. Sanctions screening against DFAT, OFAC, and UN lists must continue. If your screening engine is down, processing transactions without screening exposes you to serious penalties. Your BC plan should default to pausing transfers rather than processing unscreened ones.
The 2026 AML/CTF reforms sharpen the focus on operational risk management within your AML/CTF program. AUSTRAC increasingly expects reporting entities to demonstrate that their systems and controls remain effective under stress, not just under normal conditions. Documented DR and BC plans are evidence of that.
Defining Your RTO and RPO
Every resilience plan starts with two numbers. Get these right and the rest of your architecture follows.
Recovery Time Objective (RTO) is the maximum acceptable time to restore a system after failure. If your RTO for the core ledger is two hours, your DR architecture must bring it back within two hours.
Recovery Point Objective (RPO) is the maximum acceptable data loss, measured in time. An RPO of five minutes means you can lose no more than five minutes of transaction data — which demands near-continuous replication, not nightly backups.
Different systems justify different objectives. Set them by business criticality, not by treating everything as equal.
| System | Suggested RTO | Suggested RPO | Rationale |
|---|---|---|---|
| Core transaction ledger | 1–2 hours | Near-zero (real-time) | Lost transactions cannot be reconstructed |
| Compliance screening engine | 1 hour | 15 minutes | Cannot process transfers without it |
| Customer app / web portal | 2–4 hours | 30 minutes | Customer-facing but non-transactional data recoverable |
| Reporting & analytics | 24 hours | 4 hours | Not time-critical to transactions |
| Marketing site | 24–48 hours | 24 hours | No regulatory or transactional impact |
Aggressive RTO and RPO targets cost more. Near-zero RPO requires synchronous replication and redundant infrastructure. Match spend to the actual consequence of loss — a small MTO moving low-value Pacific corridor transfers has different needs than a high-volume platform serving the China or India corridors.
Cloud Failover Strategies for Remittance Platforms
Most Australian MTOs now run on cloud infrastructure, which changes how you architect resilience. The main failover models trade cost against recovery speed.
Multi-Availability-Zone Deployment
Deploying across multiple availability zones within a region (for example, three zones within AWS Sydney) protects against a single data centre failure. Your application runs actively across zones, so a single-zone outage causes minimal disruption. This is the baseline standard for any transactional remittance platform and the most cost-effective form of high availability.
Multi-Region Failover
Replicating to a second geographic region — say Sydney to Melbourne — protects against a full regional outage. This is more expensive and introduces latency and data-sovereignty considerations, but it removes single-region dependency for platforms where downtime is intolerable.
Data sovereignty note: if you replicate to an offshore region, you must ensure customer data handling still complies with the Privacy Act 1988 and your AUSTRAC obligations. Keeping replication within Australian regions avoids cross-border data questions entirely.
Active-Active vs Active-Passive
- Active-active: both environments handle live traffic simultaneously. Failover is instant because the second environment is already running. Highest cost, lowest RTO.
- Active-passive (warm standby): the secondary environment runs at reduced capacity and scales up on failover. Lower cost, RTO measured in minutes.
- Pilot light: minimal secondary infrastructure kept ready to activate. Lowest cost, RTO measured in tens of minutes to hours.
For most MTOs, active-passive warm standby across availability zones balances cost and recovery speed. Reserve active-active for the systems where an RTO of minutes is genuinely required, such as the compliance screening engine on a high-volume corridor.
Data Backup Obligations and Real-Time Replication
Backups and replication solve different problems, and you need both.
Replication creates a live or near-live copy of data for failover — it protects against infrastructure failure. Backups create point-in-time snapshots you can restore from — they protect against corruption, ransomware, and accidental deletion, none of which replication solves because replication faithfully copies the corruption too.
Real-Time Replication for Transaction Integrity
For the core ledger, real-time (synchronous) replication ensures that every committed transaction exists in at least two locations before it is confirmed to the customer. This delivers a near-zero RPO and protects the data most critical to your AUSTRAC record-keeping obligations — you cannot reconstruct a customer's transfer instruction if it never made it to durable storage.
Backup Strategy: The 3-2-1 Rule
A proven backup discipline for remittance data:
- Keep three copies of critical data.
- Store them on two different media or platforms.
- Keep one copy off-site (a separate cloud region or provider).
Given the seven-year retention requirement, your backup lifecycle must retain transaction and identification records for that full period in immutable, tamper-evident storage. Immutability matters: it protects records from ransomware encryption and demonstrates integrity if AUSTRAC requests historical records.
Test your restores. A backup you have never restored is a hypothesis, not a safeguard. Schedule quarterly restore tests to confirm that backups are complete, uncorrupted, and recoverable within your RTO.
Meeting AUSTRAC Record-Keeping Requirements During an Outage
This is where business continuity earns its keep. Your obligation to capture and retain records does not pause because your systems are down.
Build manual fallback procedures into your continuity plan for the moments when core systems are unavailable:
- Customer identification capture. If your eKYC platform is offline, front-desk and agent staff need a documented manual process to record customer identification details and evidence, to be entered into the system and verified once it returns.
- Transaction logging. Maintain a manual or offline log of any transactions processed during the outage so they can be reconciled and permanently recorded afterward.
- Reportable transaction flagging. Staff should flag any transaction that appears to meet TTR (AUD 10,000+ cash) or IFTI thresholds so reports can be lodged within the required timeframe once systems recover.
- Sanctions screening decision. Default policy should be to hold transactions that cannot be screened rather than release them. Document this decision and the affected transactions.
The safest posture during an outage is often to pause new high-risk activity rather than process transactions you cannot properly capture, screen, or record. AUSTRAC is far more understanding of a documented, deliberate pause than of a flood of unscreened, unrecorded transactions.
Document everything about the outage. The cause, duration, systems affected, decisions made, and reconciliation steps taken. This record demonstrates that your controls remained effective and shows good faith if AUSTRAC reviews the incident.
Building a Business Continuity Plan for Your MTO
A usable BC plan is specific, tested, and known to your team. A plan sitting unread in a shared drive protects nobody.
Core components
- Business impact analysis: identify your critical functions (settlement, compliance screening, customer transfers) and the maximum tolerable disruption for each.
- Roles and responsibilities: name the incident commander and define who decides to invoke DR, who communicates with agents and customers, and who handles regulatory notifications.
- Communication plan: pre-drafted messages for staff, agents, customers, your PSP, and payout partners. Include contact trees that work when email or the primary system is down.
- Manual workarounds: the fallback procedures for KYC, transaction logging, and reporting described above.
- Supplier dependencies: DR arrangements for your PSP, screening vendor, and payout network. Their outage is your outage — understand their RTO commitments.
- Recovery and reconciliation: the step-by-step process for validating data integrity and reconciling manual records once systems return.
Testing cadence
| Test type | Frequency | What it validates |
|---|---|---|
| Backup restore test | Quarterly | Backups are recoverable within RTO |
| Failover drill | Twice yearly | DR failover works and meets RTO |
| Tabletop exercise | Annually | Staff know their BC roles |
| Full BC simulation | Annually | End-to-end resilience under realistic conditions |
After each test, record what worked, what failed, and what you changed. This continuous-improvement loop is exactly what AUSTRAC expects to see in a mature reporting entity.
Common Resilience Gaps in Remittance Operations
Even MTOs with strong technical DR routinely leave these gaps:
- No manual compliance fallback. Systems recover but staff had no process for KYC or reporting during the outage.
- Untested backups. Backups run nightly but nobody has confirmed a restore works.
- Single supplier dependency. The PSP or screening vendor has no redundancy, and their outage halts operations regardless of your own resilience.
- Ignoring the reconciliation gap. Transactions processed manually during an outage are never fully reconciled into permanent records, creating a record-keeping breach.
- Plans that only exist on paper. A BC plan never rehearsed fails under real pressure.
Work through each of these against your own operation. The cheapest resilience improvement is usually a documented manual process, not new infrastructure.
FAQ
What is the difference between disaster recovery and business continuity?
Disaster recovery is the technical process of restoring IT systems and data after a failure — it answers how do we get the technology back? Business continuity is the broader operational plan that keeps your business functioning and your obligations met during and after the disruption — it answers how do we keep serving customers and meeting compliance obligations until systems return? Remittance operators need both.
Does an IT outage extend AUSTRAC reporting deadlines?
No. Obligations such as TTR and IFTI reporting (both due within 10 business days) and seven-year record retention continue regardless of system availability. Your business continuity plan must include manual procedures to capture reportable data during an outage so you can lodge reports on time once systems recover.
How often should an MTO test its disaster recovery plan?
Run failover drills at least twice yearly and backup restore tests quarterly. Conduct an annual full business continuity simulation and tabletop exercise so staff know their roles. Untested backups and unrehearsed plans are the most common reasons resilience fails when it matters.
What RPO should a remittance platform target for its transaction ledger?
Aim for a near-zero RPO on the core transaction ledger, achieved through real-time (synchronous) replication. Lost transaction data cannot be reconstructed and directly threatens your AUSTRAC record-keeping obligations, so this is the one system where minimal data loss justifies the higher cost of continuous replication.
Can I replicate my remittance data to an offshore cloud region?
You can, but doing so raises data-sovereignty questions under the Privacy Act 1988 and may complicate your AUSTRAC obligations. Keeping replication within Australian cloud regions (for example Sydney to Melbourne) avoids cross-border data-handling issues entirely and is the simpler compliant choice for most MTOs.
Next Steps for Your MTO
Start by defining an RTO and RPO for each critical system, then map your current architecture against those targets to find the gaps. Pair every technical recovery capability with a documented manual fallback for KYC, transaction logging, and reporting — that pairing is what turns a DR plan into genuine resilience.
Review how your resilience controls fit within your broader AML/CTF program using our AML/CTF program tool, and prepare for regulatory scrutiny with our related guidance on operational risk. If you also want to strengthen the compliance software underpinning your platform, our guide on choosing AML compliance software is a useful companion.
This information is general in nature and does not constitute legal advice. Consult AUSTRAC or a qualified legal professional for advice specific to your situation.
