Regulatory Reporting for an Australian Mutual Bank
Designed and built a clickable regulatory reporting platform for an Australian customer-owned bank: prepare APRA returns from core banking and general ledger data, clear validation errors, comment on variances, approve adjustments within policy limits and sign off against an evidence pack, with every reported number traceable to its source.
Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.
Dashboard, returns register with quick view, return workspace with 8 tabs, sign-off queue and adjustments register. Every one of the 21 demo returns opens its own workspace.
Data loaded, GL reconciliation passed, errors cleared, warnings explained, variances commented and adjustments approved. Send for sign-off stays disabled until all six are ticked.
A reviewer approves adjustments up to AUD 5m or 0.05 pts on a key ratio; anything larger waits for the accountable executive. Nobody can approve an adjustment they raised.
11 APRA forms, 25 validation rules, 15 adjustments in every status, 6 data sources, 10 staff users and 8 quarters of filing timeliness.
Tallowood's four-person financial reporting team built about 40 returns a quarter in Excel workbooks fed by manual extracts, each with its own macros and owner, and keyed the figures into APRA Connect by hand. The only record of why a number moved was an email thread, a late capital correction led to a resubmission and a three-week APRA query, and a missed branch file meant 14 AUSTRAC threshold transaction reports were lodged late.
Plimsoll turns core banking and general ledger data into the returns the bank owes APRA and AUSTRAC. Preparers work each return in one workspace with validation, variance commentary, adjustments and GL reconciliation side by side, reviewers approve changes within a fixed policy, and the accountable executive signs off against the evidence pack they were shown.
An Australian ADI owes APRA prudential and statistical returns under its reporting standards and owes AUSTRAC transaction reports under the AML/CTF Act. Each has its own form, deadline and sign-off, and the person who signs is personally accountable for it.
The Chief Financial Officer, the accountable person for financial reporting under the Financial Accountability Regime, was signing returns he could not trace back to source. CPG 235 sets expectations on data quality, validation and lineage that a chain of workbooks could not show.
The internal auditor's review of reporting controls found no record of reviews or approvals. APS 310 generally requires the external auditor to report on those controls, and reporting standards generally require submitted data to be signed off by an authorised officer.
Each APRA standard sets its own frequency and due date. AUSTRAC threshold transaction and international funds transfer reports are generally due within 10 business days, counted around NSW public holidays, and the AML/CTF Amendment Act 2024 changes some obligations in stages from 2026.
A single return draws on core banking, the general ledger, treasury, the teller system and the payments gateway. One late or failed load changes the numbers, and customer data in transaction reports is personal information under the Privacy Act 1988.
Mapped 8 user roles, 34 screens (33 staff screens and a mobile sign-off screen for accountable executives) and the data model for forms, obligations, return instances, cell values, mappings, validation rules, adjustments, reconciliation, sign-off policies, evidence packs, submissions, AUSTRAC batches, lineage and a hash-chained audit trail. Wrote down the rules the design follows: the Financial Sector (Collection of Data) Act 2001 and the ARS series, APRA Connect lodgement, APS 310, FAR, CPS 230, CPG 235, the AML/CTF Act 2006 and its 2024 amendments, tipping-off limits on SMRs and the Privacy Act 1988.
Built 5 key screens on a production dashboard kit: the dashboard with filing KPIs, the next 10 APRA and AUSTRAC deadlines, data readiness per source and 8 quarters of timeliness, the returns register, the return workspace with form grid, cell lineage, validation, variance, adjustments, reconciliation, sign-off, submissions and activity tabs, the sign-off queue with attestation and MFA, and the adjustments register. Approving a pending adjustment clears its validation error and unlocks sign-off. All actions run on local state.
Integration with core banking (such as Data Action, Ultradata or Temenos), the general ledger (Oracle Fusion Cloud ERP, SAP S/4HANA or TechnologyOne), treasury, the payments feed, a Snowflake or Azure Synapse landing zone, APRA Connect and AUSTRAC Online lodgement, Entra ID or Okta SSO with MFA, evidence storage and Teams alerts. The remaining screens: reporting calendar, submissions and resubmissions, AUSTRAC batches and SMR log, data sources, lineage explorer, mappings and rules with change control, audit trail, reports, settings and mobile sign-off.
Clicking any cell on the form opens its lineage: the source systems that feed it and the mapping that placed it. Totals are computed and cannot be edited, and a toggle switches between as mapped and as adjusted values.
The readiness bar under each return shows its six checks. Errors block sign-off, warnings need an explanation, and any movement over both 10% and AUD 1m needs commentary before the return can move on.
Every adjustment carries a reason category, evidence, its before and after values and its impact on a key ratio. The policy decides who may approve it, approve and reject need a comment, and a reversal creates an offsetting entry instead of deleting the original.
Each return pins its data snapshot, form, mapping and rule set versions. The accountable executive signs from an evidence pack of key figures, validation, reconciliation, adjustments and top variances, confirms with an MFA code, and can only delegate to their named alternate.

Designed and built a clickable AML transaction monitoring system for a US neobank and its sponsor bank: scenario alerts ranked by a transparent priority score, an investigation workspace that shows why each alert fired, real-time payment holds, and cases that count down to the SAR filing deadline.

Designed and built a clickable KYC and KYB case-management platform for a Vilnius electronic money institution: a case queue with SLAs, individual and business cases with registry comparison and beneficial ownership traced through every layer, an explainable risk score, four-eyes approval and requests for information sent to customers.
Enterprise Software Engineering - Human + AI
Contact Us
© 2026 - Copyright. All Rights reserved Oceanlab
Location
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
Enterprise Software Engineering - Human + AI
Contact Us
Locations
Global Headquarters
21 Merchant Road, 3rd Floor, Singapore 058267
Main corporate office and leadership operations
North America Office
548 Market Street, PMB 12345, San Francisco, CA 94104
Client operations and business development
India Office
402 Shivalik Shilp II, SG Highway, Ahmedabad 380015
Engineering and delivery center
© 2026 - Copyright. All Rights reserved Oceanlab