The Regulatory Crossfire: Why the humble ABA file is now a Boardroom Liability

In the world of Enterprise ERP, there is a specific moment of exposure that happens thousands of times a day across Australia.

A Finance Officer sits in a beautifully secured office. They are logged into a Microsoft Dynamics 365 environment protected by Multi-Factor Authentication (MFA), Conditional Access Policies, and Microsoft Entra ID. The database behind them is encrypted at rest. The connection is TLS 1.3.

Then, they click a button labeled "Export."

A plain-text ABA (Australian Bankers Association) or ISO20022 file—containing millions of dollars in payroll or vendor payments—is downloaded to a local C:\Downloads folder.

For the next 15 minutes, that file sits on a laptop.

• It is unencrypted.
• It is editable in Notepad.
• It is invisible to the audit log.
• It is then manually uploaded to a banking portal like CommBiz or NAB Connect.

Ten years ago, this was accepted as the standard "Last Mile" of finance.

Today, under the SOCI Act (2018/2021) and the precedent set by ASIC v RI Advice, this workflow has shifted from a process inefficiency to a breach of Director duties.

This article outlines the specific regulatory crossfire you are walking into every time your team presses "Export," and why the "Plaintext Gap" persists in even the most sophisticated enterprises.

---

The Barrier: Why the Gap Exists

Before we analyze the law, we must understand the engineering reality. Why do ASX-listed companies still use text files in 2026?

It is not negligence. It is The Complexity Trap.

Modern ERPs like Dynamics 365 are born in the Cloud. They speak modern languages: REST APIs, JSON, OData, and OAuth 2.0.

Banks, conversely, often run on legacy infrastructure. Their "Host-to-Host" gateways speak the languages of the 1990s: SFTP, PGP Encryption, and fixed-width text files.

Bridging these two worlds is exponentially difficult. To build a "Sovereign Tunnel" in-house, a company needs to:

1. Provision secure cloud infrastructure (Azure Logic Apps/Functions).
2. Manage HSM-backed Key Vaults for PGP keys.
3. Configure complex Virtual Networks (VNETs) and NAT Gateways for IP Whitelisting.
4. Write custom code to translate JSON into complex ISO20022 schemas.

The Cost of "Doing it Right": A bespoke, secure banking integration often costs $150,000 to $500,000 in consulting fees and takes 6 months to build. For many partners, the risk is too high to even attempt it.

So, the manual CSV export becomes the default. It is the only "accessible" bridge across the chasm. But while it solves the connectivity problem, it creates a massive liability problem.

---

1. The SOCI Act (Security of Critical Infrastructure)

The Trigger: Exporting payment data to an unmanaged or local device.

If you operate in Energy, Utilities, Logistics, Data Processing, or Food Supply, you are likely captured by the Security of Critical Infrastructure Act 2018 (and its 2021 amendments).

Under the SOCI Risk Management Program (RMP) rules, entities must identify and mitigate "material risks" to their critical assets. "Critical Assets" include the data required to operate the service—including financial data.

• The Violation: A manual ABA file creates a "Plaintext Gap" in your supply chain. It allows a compromised endpoint (the laptop) to alter the instruction before it reaches the Critical Infrastructure Sector (the Banking Grid).
• The "Material Risk": If a ransomware actor exfiltrates that file, or modifies it to redirect funds, you have failed to maintain the integrity of Business Critical Data.
• The Consequence: Under SOCI, a failure to secure the supply chain isn't just an IT ticket; it is a federal compliance failure reportable to the Department of Home Affairs.

2. ASIC v RI Advice (The Personal Liability Precedent)

The Trigger: Directors failing to mandate secure architecture.

The Federal Court ruling in ASIC v RI Advice Group Pty Ltd set a terrifying precedent for Australian Directors: You are personally liable for cyber resilience.

Justice Rofe made it clear that cyber risk management is not just for the IT department; it is a core fiduciary duty. The ruling stated that entities must take "reasonable steps" to manage cybersecurity risks.

• The Argument: Can a Director claim they took "reasonable steps" to protect company assets if they allowed the primary mechanism for funds transfer to be an unencrypted text file sitting on a desktop?
• The Verdict: Likely No. While the technical barrier is high, relying on manual files is a choice to accept risk that the courts may deem unreasonable given the availability of modern infrastructure solutions.

3. ISO 27001 & SOX (The Audit Trail)

The Trigger: Editing a file in Notepad to fix a "formatting error."

For multinational entities, Sarbanes-Oxley (SOX) Section 404 requires strict internal controls over financial reporting. ISO 27001 requires strict control over information transfer.

• The Violation (ISO A.5.14 - Information Transfer): Information involved in application services passing over public networks must be protected from fraudulent activity, unauthorized disclosure, and modification. A file on a desktop is protected by nothing but the user's login.
• The Violation (SOX - Integrity): When a file is edited in Notepad, the Integrity attribute of the CIA triad (Confidentiality, Integrity, Availability) is shattered. An auditor cannot verify that the file uploaded to the bank matches the file approved in the ERP.
• The Result: Automatic Audit Qualification (Failure).

4. APRA CPS 234 (For Financial Institutions)

The Trigger: Using a third-party laptop to bridge the gap.

For our clients in Insurance and Superannuation, APRA CPS 234 mandates strict information security controls.

• The Requirement: Entities must classify information assets by criticality and sensitivity. Payment files are High Criticality.
• The Violation: Storing High Criticality data on a laptop (Data at Rest) without specific encryption keys managed by the entity violates the principle of secure storage. If the laptop is stolen, the data is compromised.

---

The Anatomy of an Attack

How does the fraud actually happen? It is rarely a sophisticated "Ocean's Eleven" heist. It is usually Malware or Social Engineering.

1. The Entry: A Finance Officer clicks a phishing link. A "sleeper" trojan is installed on their machine.
2. The Watch: The malware scans for files ending in .aba or .xml appearing in the Downloads folder.
3. The Swap: When a new file appears, the malware parses the text in milliseconds. It swaps the Vendor's BSB/Account Number for a "Mule Account" number. It recalculates the checksum (if applicable) and saves the file.
4. The Upload: The user, unaware, uploads the file to the Bank Portal. The Bank sees a valid file. The ERP sees a valid payment run.
5. The Loss: The money is gone. The ERP says "Paid to Supplier." The Bank says "Paid to Instruction." The gap is where the liability lives.

---

The Architectural Fix: The Sovereign Tunnel

The goal of Demiton is to democratize "Critical Infrastructure Grade" banking. We absorb the complexity of the legacy banking grid so that Partners and Clients don't have to build bespoke tunnels.

At Demiton, we utilize a "Ghost Protocol" architecture.

Run the simulation below to see how a RAM-Only execution pipeline handles a payment event versus a manual process.

The Demiton Architecture enforces compliance by design:

1. RAM-Only Execution (No Disk Persistence)

We stream payment data from Dynamics 365 directly into Volatile Memory (RAM). The transformation (JSON to ABA) and the encryption happen in memory.

• Compliance Win: If the server is seized or compromised, there is no data on the disk to steal. The moment the transaction is done, the RAM is flushed. This satisfies ISO 27001 Data Minimization.

2. Protocol Zero (Identity Binding)

We re-authenticate the user at the moment of payment generation using Microsoft Entra ID. We take the user's Identity Token and cryptographically bind it to the SHA-256 hash of the payment payload.

• Compliance Win: Non-Repudiation. We can prove mathematically who authorized the file and that the file was not altered after authorization. This satisfies ASIC / SOX.

3. Sovereign Exit (Data Residency)

Cloud IPs are dynamic. To solve this, we use a Sovereign NAT Gateway locked strictly to Azure Australia East.

• Compliance Win: Data Sovereignty. We guarantee that the data payload never leaves the Australian jurisdiction, satisfying the SOCI Act and Privacy Act.

The Director's Checklist

If you are a Board Director or CFO, ask your CIO these three questions in the next Risk Committee meeting:

1. "Does any unencrypted payment data sit on a laptop at any point in our process?"
2. "If a file is edited in Notepad before upload, does our ERP know about it?"
3. "Can we prove the Chain of Custody for the payment file sent yesterday?"

If the answer to any of these is "I don't know," you are carrying liability you don't need.

Explore the Sovereign Architecture Specs →