APRA and ASIC: test your mobile banking app the way the texts describe it.
CPS 234 requires a systematic testing program for the controls that protect information assets, and CPG 234 says a sufficient set of controls should be tested at least annually, with controls exposed to untrusted environments tested throughout the year. A mobile banking app and the APIs behind it sit in exactly that environment. Ostorlab tests them on every release, behind login, and the Scams Prevention Framework and the Consumer Data Right add their own controls to the same app.
- Tests the app and the APIs behind it on the build customers download, with evidence for each release
- Covers the controls CPG 234 names, from vulnerability management to secure development and customer protections
- Logs in with your test accounts and completes one-time codes to test payments, payee changes and sessions
- Maps findings to the APRA, Scams Prevention Framework and Consumer Data Right clauses they help you evidence
- Who it applies to
- ADIs and other APRA-regulated entities for CPS 234 and CPS 230; banks as Consumer Data Right data holders; banks in the Scams Prevention Framework banking sector
- Key dates
- CPS 234 in force since 1 July 2019; CPS 230 since 1 July 2025, with amendments effective 1 July 2026; most Scams Prevention Framework duties from 31 March 2027
- Focus
- Systematic testing of information security controls, app and API testing, third party and data risk, scam controls and Consumer Data Right API security
- Main references
- CPS 234 and CPG 234, CPS 230, CPG 235, the Scams Prevention Framework Act 2025, the Consumer Data Right Rules and the Privacy Act 1988
The Australian texts behind your mobile channel
The prudential standards set the baseline for information security and operational risk. The scams and data sharing regimes have been added on top since 2025. The dates below are for the texts cited on this page.
- September 2013
CPG 235 Managing Data Risk
APRA publishes its practice guide on data risk across the data lifecycle, from capture and processing to retention, publication and disposal, including outsourcing and offshoring.
- 1 July 2019
CPS 234 Information Security
The prudential standard takes effect, requiring an information security capability, controls and a systematic testing program. Requirements for assets managed by third parties applied from the earlier of the next contract renewal or 1 July 2020.
- 1 July 2025
CPS 230 Operational Risk Management
The new cross-industry standard commences, covering operational risk controls, business continuity and the management of service providers, with a transition period for existing contracts.
- 29 May 2026
Scams Prevention Framework designation
The designation of covered banking services commences. ASIC becomes the sector regulator, and AFCA membership is required from 1 September 2026. Most obligations apply from 31 March 2027.
- 1 July 2026
CPS 230 amendments in force
The targeted amendments finalised on 30 April 2026 take effect, and all CPS 230 requirements now apply to every APRA-regulated entity, including non-significant financial institutions.
- 31 March 2027
Scams duties for banks
Most Scams Prevention Framework obligations apply to banking: governance, prevention, detection, reporting, disruption, internal dispute resolution and the external dispute resolution scheme.
The Australian rules, applied to your mobile app
For each rule: what the text says, what it means for a mobile banking app, how Ostorlab helps, and what stays with your team. CPS 234 and CPS 230 are prudential standards; CPG 234 and CPG 235 are guidance.
- CPS 234, paragraphs 27 to 31; CPG 234, Testing control effectiveness
Test information security controls systematically
What the text says
An APRA-regulated entity must test the effectiveness of its information security controls through a systematic testing program. The nature and frequency must be commensurate with how fast vulnerabilities and threats change, the criticality and sensitivity of the asset, the consequences of an incident, the risks of exposure to environments where the entity cannot enforce its policies, and the materiality and frequency of change to information assets. Testing must be conducted by appropriately skilled and functionally independent specialists, and the sufficiency of the program reviewed at least annually or when there is a material change. CPG 234 adds that the frequency and scope should cover a sufficient set of controls at least annually, and that controls protecting assets exposed to untrusted environments, including the internet, should be tested throughout the year.
Source:CPS 234, paragraphs 27 to 31; CPG 234, Testing control effectiveness
What it means for your mobile app
A mobile banking app and its APIs are internet-facing information assets that change with every release. They belong in the systematic testing program, and the release cadence should drive how often they are tested, not only the annual review.
How Ostorlab helps
Ostorlab runs automated scans from your CI/CD pipeline on every build and monitors store releases without manual triggers. An AI-agent pentest tests the app and its APIs behind login, and every AI-agent finding comes with a working exploit you can replay.
What stays with you
The testing program itself, decisions on tester independence, escalation of control deficiencies that cannot be remediated in time, and internal audit.
- CPS 234, paragraph 21; CPG 234, Implementation of controls
Manage vulnerabilities with response deadlines
What the text says
Information security controls must be commensurate with the vulnerabilities and threats to the information assets. CPG 234 expects vulnerability management controls that identify and address vulnerabilities in a timely manner, and patch management controls that manage the assessment and application of patches and other updates that address known vulnerabilities in a timely manner. These expectations cover information assets managed by third parties and related parties, and feed the assurance the Board receives on the control environment.
Source:CPS 234, paragraph 21; CPG 234, Implementation of controls
What it means for your mobile app
The SDKs and native libraries inside your app are software you ship. Each one needs a known version, a severity when a vulnerability appears, and a fix deadline you can prove. The same applies to the backend components the app depends on.
How Ostorlab helps
SCA fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Findings are rated critical, high, medium or low, tracked as tickets in the platform or in Jira and ServiceNow, and retested once the fix ships.
What stays with you
Patching servers and infrastructure, vendor maintenance contracts, risk acceptance decisions and reporting to the Board.
- CPG 234, Attachment D (Software security) and Security in change management
Build security in and test every change
What the text says
APRA expects information security considerations throughout the software delivery life cycle, including where agile techniques are used: requirements, design, selection and configuration, testing and implementation. Security in change management includes security testing and reviews to identify vulnerabilities and confirm that information security requirements have been met, with the nature of testing commensurate with the scope of the change and the sensitivity of the affected asset, and approval of changes before deployment into production. Software standards should cover areas such as authentication, authorisation, session management, data validation, cryptography, logging and secure input and output handling.
Source:CPG 234, Attachment D (Software security) and Security in change management
What it means for your mobile app
Every app release is a change to an internet-facing asset. Automated tests belong in the pipeline before the build reaches the store, and the SDKs bundled into the app are part of the change.
How Ostorlab helps
Mobile SAST analyses the APK, AAB or IPA directly, with no source code needed, including taint analysis across embedded SDKs. Mobile DAST runs the app and captures traffic, stack traces and screenshots. Both run from your CI/CD pipeline on every build.
What stays with you
Secure coding standards, developer training, manual code review and the approval decision before production.
- CPS 234, paragraphs 16, 20, 22 and 28; CPG 234, Information asset identification and classification
Know your information assets and your third parties
What the text says
An APRA-regulated entity must classify its information assets, including those managed by related parties and third parties, by criticality and sensitivity. Where information assets are managed by a related party or third party, the entity must assess that party's information security capability, evaluate the design of its information security controls, and, where it relies on the party's control testing, assess whether the nature and frequency of that testing is commensurate with the standard's factors.
Source:CPS 234, paragraphs 16, 20, 22 and 28; CPG 234, Information asset identification and classification
What it means for your mobile app
Your asset inventory should include the mobile app, the APIs it calls and the SDKs it embeds. A white-label app or a vendor-built release still carries your obligations.
How Ostorlab helps
Ostorlab lists the SDKs and native libraries in each release with their versions and their location in the app bundle, and shows what the app and its SDKs exchange with backends over the network. Ostorlab is SOC 2 Type II audited, and the report is available on request.
What stays with you
The asset register, third party due diligence, contracts and decisions about relying on a vendor's testing.
- CPG 235, Data life-cycle management, Retention, Desensitisation and Outsourcing/offshoring; CPS 230, paragraph 23
Manage data risk across the data lifecycle
What the text says
CPG 235 expects data risk to be considered at each stage of the data lifecycle: capture, processing, retention, publication and disposal. It expects retention controls and a formal retention strategy, desensitisation such as encryption or de-identification when data moves to a less trusted environment, auditability of data and its changes, and a cautious assessment of outsourcing and offshoring, including the ability to continue operations, meet prudential requirements and give APRA timely access to data in a usable form. CPS 230 names data risk among the operational risks an entity must manage.
What it means for your mobile app
Account data, tokens and personal information on the phone are part of the data lifecycle. Retention and desensitisation decisions apply to caches, logs, screenshots and local storage, not only to databases.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections.
What stays with you
Data classification, retention schedules, desensitisation policy, data governance and offshoring assessments.
- CPG 234, Attachment F (Customer security)
Protect customers on digital channels
What the text says
CPG 234 sets out controls for products and services delivered through digital channels: authentication commensurate with the threats, second channel notification or confirmation for events such as account transfers, new payees, a change of address or access from an unrecognised device; limits such as transfer and daily transaction limits; transaction activity monitoring; documented procedures for fraud, data leakage and identity theft; and minimising the collection of sensitive customer information used for authentication, such as passwords and PINs.
What it means for your mobile app
MFA, step-up checks, notifications and limits have to be enforced by the backend on every key operation, including when the app or an attacker tries to skip a step.
How Ostorlab helps
Ostorlab logs in with your test accounts, completes SMS, email or TOTP one-time codes, and tests MFA enforcement and step-up flows, including how attackers try to manipulate them, together with the API calls behind account changes, payees and transfers.
What stays with you
The choice of authentication methods, transaction limits, fraud monitoring and customer education.
- CPS 230, paragraphs 29, 48 to 50 and 60
Treat operational risk and service providers as one system
What the text says
CPS 230 requires an entity to regularly monitor, review and test controls for design and operating effectiveness, with a frequency commensurate with the materiality of the risks being controlled, and to report the results to senior management and rectify gaps or deficiencies in a timely manner. It must identify and maintain a register of material service providers, submit that register to APRA annually, notify APRA within 20 business days of entering into or materially changing an agreement for a service it relies on for a critical operation, and notify APRA before a material offshoring arrangement. Risk management, core technology services and internal audit must be classified as material service providers unless the entity can justify otherwise.
What it means for your mobile app
The app depends on core technology services and on SDK and API vendors. The controls that keep it working are part of the operational risk profile, and the evidence you keep should match the register and the Board reporting.
How Ostorlab helps
Automated scans on every build give a dated result per release, and the AI-agent pentest covers the app and its APIs behind login. On the Enterprise plan you can choose Asia-Pacific data residency or run scans on-premises, and Ostorlab is SOC 2 Type II audited.
What stays with you
The service provider register, contracts, Board reporting, APRA notifications and business continuity.
- Scams Prevention Framework Act 2025, sections 58BD, 58BE, 58BJ, 58BM, 58BN, 58BO, 58BX, 58BZC, 58BZD and 58BZG; Designation 2026, sections 11, 12 and 101
Prepare the app for the Scams Prevention Framework
What the text says
The Scams Prevention Framework Act 2025 added the framework to the Competition and Consumer Act 2010. Regulated entities must document and implement governance policies and procedures for preventing, detecting and disrupting scams, responding to scams and reporting on scams, with performance metrics and an annual written certification by a senior officer. They must take reasonable steps to prevent another person from committing a scam, take reasonable steps to detect a scam as it happens and after it happens, investigate actionable scam intelligence within 28 days, identify impacted consumers, take reasonable steps within a reasonable time to disrupt an activity or prevent loss or harm, provide an accessible mechanism to report scams, run an accessible and transparent internal dispute resolution process, and belong to an external dispute resolution scheme. The Designation 2026 brings covered banking services into the framework, with ASIC as the sector regulator. Most obligations apply from 31 March 2027, and AFCA membership is required from 1 September 2026.
What it means for your mobile app
Several of these duties land in the app: payment disruption, in-app warnings, the reporting mechanism and the complaint flow. If a control can be bypassed through the app or its APIs, the reasonable steps argument gets weaker.
How Ostorlab helps
The AI-agent pentest tests the business logic of payment and account flows, and API testing checks authorization and replay on the calls behind payments and account changes, so you can see whether app-side friction holds at the backend.
What stays with you
Governance policies and metrics, the annual certification, scam surveillance and reporting to ASIC, complaints handling and AFCA membership.
- Consumer Data Right Rules 2020, rules 1.15, 4.25 and 4.27 and Schedule 2; Consumer Data Standards 1.36.0, Security Profile (Authentication Flows); Competition and Consumer Act 2010, section 56ES
Meet the Consumer Data Right API profile
What the text says
Under the Consumer Data Right in Part IVD of the Competition and Consumer Act 2010, banks are data holders that must disclose CDR data through CDR APIs when a consumer asks or an accredited person asks on their behalf, and must provide a consumer dashboard that lets consumers manage and withdraw their authorisations to disclose CDR data. The Consumer Data Standards set the technical baseline. In the security profile, data holders must support FAPI 1.0 Advanced, and must also support JARM and PKCE; data recipient software must use PAR with PKCE and the S256 challenge method. The rules set out the steps and minimum information security controls for accredited data recipients and designated gateways, and eligible data breaches involving CDR data are handled under the Notifiable Data Breaches scheme.
What it means for your mobile app
If your mobile app is the consumer dashboard, the authorisation screens and the withdrawal flow are part of the CDR surface. The CDR API endpoints need the same testing as the rest of your API estate, with the added FAPI requirements.
How Ostorlab helps
Ostorlab intercepts the app's traffic, even with TLS pinning, and tests authentication and authorization on the APIs, including OIDC flows, token handling, authorisation withdrawal calls and access to other customers' data.
What stays with you
Accreditation and CDR policy matters, consent and dashboard design, CDR data governance and breach notification.
- Privacy Act 1988, Schedule 1, APP 11 and Part IIIC; OAIC APP Guidelines, Chapter 11 (updated 3 October 2025); Privacy Amendment (Personal Data Protection) Bill 2026 (exposure draft)
Secure personal information under the Privacy Act
What the text says
The Privacy Act 1988 requires APP entities to take reasonable steps to protect personal information from misuse, interference and loss, and from unauthorised access, modification or disclosure, and to destroy or de-identify information that is no longer needed. Since 11 December 2024, APP 11.3 makes clear that reasonable steps include technical and organisational measures. Under the Notifiable Data Breaches scheme in Part IIIC, an entity must notify the OAIC and affected individuals when a data breach is likely to result in serious harm. The OAIC guidance on APP 11, updated in October 2025, points to ICT security, access security and third party providers among the areas to cover. A second tranche of privacy reforms was released as an exposure draft in August 2026 and is not yet law.
What it means for your mobile app
Passwords, tokens, account numbers and personal data should not sit in clear text on the phone or travel unprotected to the backend. What the app writes to logs, caches and screenshots counts.
How Ostorlab helps
Ostorlab looks for session tokens and personal data in local storage, caches, logs and screenshots, and checks for misconfigurations that weaken transport and session protections.
What stays with you
The privacy program, retention and destruction decisions, breach assessment and notification, and your privacy policy.
Summary of public APRA, Australian Government and OAIC texts, checked on 27 September 2026. CPS 234 and CPS 230 are prudential standards made under the Banking Act 1959; CPG 234 and CPG 235 are guidance. The Scams Prevention Framework codes and rules for banking were still in exposure draft when this page was checked. This page is not legal advice.
Australian rules, control by control
The controls the texts point to, how Ostorlab tests them in your app and its APIs, and the evidence you can keep.
| Control | How Ostorlab helps | Evidence you keep |
|---|---|---|
| Systematic testing of information security controlsCPS 234, paragraphs 27 to 31 | AI-agent pentest of the app and its APIs, behind login, on the build you ship, plus automated scans in CI/CD. Details | A working exploit you can replay for each AI-agent finding, and scan results per build |
| Vulnerability and patch management for shipped componentsCPS 234, paragraph 21; CPG 234 | Fingerprints statically compiled libraries and maps them to known vulnerabilities, release to release. Details | Mapped vulnerabilities with upgrade or replace recommendations, and closure tracked across releases |
| Security testing in change management and secure developmentCPG 234, Attachment D and change management | Mobile SAST on the binary and Mobile DAST on the running app, from your CI/CD pipeline. Details | Findings with decompiled source context, traffic, stack traces and screenshots |
| Third party capability and control designCPS 234, paragraphs 16, 22 and 28 | Lists the SDKs and native libraries in each release and shows the backends they talk to, so vendor components are visible. Details | Component identity, version and location in the app bundle, per release |
| Data lifecycle controls on the deviceCPG 235, data life-cycle management | Looks for tokens and personal data in storage, caches, logs and screenshots, and checks transport protections. Details | File system evidence showing what was written, where and when |
| Authentication, notifications and limits on digital channelsCPG 234, Attachment F | Logs in with one-time codes and tests MFA enforcement, step-up flows and the API calls behind payees and transfers. Details | Findings on login and step-up flows, with reproduction steps |
| Control testing and material service providersCPS 230, paragraphs 29 and 48 to 50 | Dated scan results per release, and a SOC 2 Type II report for your vendor due diligence. Details | SOC 2 Type II report, on request from the Trust Center |
| Scam prevention, detection and disruptionSPF Act 2025, Part IVF principles | Tests the business logic of payment and account flows, including whether app-side friction holds at the backend. Details | Reproduction steps and request and response evidence for each flow |
| Consumer Data Right API security profileCDR Rules 2020 and Consumer Data Standards 1.36.0 | Intercepts traffic even with TLS pinning and tests authentication, tokens and authorization, including authorisation withdrawal calls. Details | Request and response evidence for each API finding |
| Security of personal information in the appPrivacy Act 1988, APP 11 | Finds API keys, tokens and credentials in the app package and validates whether they work, alongside checks of data left on the device. Details | Validated secrets, with the permissions and services they expose |
Ostorlab tests controls in the app and its APIs. Governance, Board reporting, APRA incident notifications, scam surveillance, complaints handling, TLPT and red teaming, recovery and physical security stay with your teams.
Australian controls to test in your mobile app
A practical list for security and technology risk teams, based on the APRA texts, the Scams Prevention Framework and the Privacy Act.
Testing program
Put the mobile app and its APIs in the systematic testing program, and let release frequency and threat change drive the cadence.
Components and deadlines
Keep a versioned list of the SDKs and libraries in each release, and set fix deadlines by severity.
Pipeline gates
Run static and dynamic tests on every build before it reaches the store, and keep the results per release.
Third parties
Include SDK and service provider components in your asset and provider registers, and ask vendors for test evidence.
Data on the device
Look for tokens and personal data in storage, caches, logs and screenshots, and check retention and desensitisation decisions against the app.
Customer protections
Test MFA, step-up checks, notifications and limits behind login, including payee changes and transfers.
Scam readiness
Walk through payment disruption, in-app reporting and the complaint flow against the Scams Prevention Framework principles before March 2027.
Consumer Data Right and privacy
Test authorisation withdrawal and access control on the CDR APIs, and keep evidence for the data breach and privacy obligations.
A suggested list, not an APRA, ASIC or OAIC template. This is not legal advice.
The capabilities behind this page
Each one has its own page with the details.
- Mobile Agentic Deep ScanAI agents pentest the store build on every release, with a working exploit you can replay for each AI-agent finding.Learn more
- Authenticated testingTest login, one-time codes and step-up flows with your test accounts.Learn more
- API and backend testingIntercept app traffic even with TLS pinning, then test the APIs and backends behind accounts and payments.Learn more
- Mobile SASTBinary-based static analysis of APK, AAB and IPA files, with taint analysis across the app and its embedded SDKs.Learn more
- SCA and SBOMFind vulnerable dependencies, including statically compiled native libraries, and track their closure release after release.Learn more
- Mobile Shielding ScanTest root and jailbreak detection, anti-tampering and pinning at runtime, and see which protections held and which were bypassed.Learn more
- Bring your own AI keyRun AI-agent scans on your own AI provider key with a spend cap per scan, so usage follows your internal policies.Learn more
- On-premises scanningScan staging apps, APIs and repositories behind your firewall or VPN, on infrastructure you control.Learn more
Trusted by banks and fintechs, including
Sources
The official texts this page is based on, checked on 27 September 2026.
- Prudential Standard CPS 234 Information SecurityAPRA, made on 30 November 2018, in force from 1 July 2019. Information security capability, controls, systematic testing, internal audit and notification (paragraphs 13 to 36)
- Prudential Practice Guide CPG 234 Information SecurityAPRA, June 2019. Guidance on CPS 234, including testing control effectiveness, information asset classification, software security (Attachment D), customer security (Attachment F) and testing techniques (Attachment G)
- Prudential Standard CPS 230 Operational Risk ManagementAPRA, commenced on 1 July 2025. The version in force from 1 July 2026 incorporates the targeted amendments finalised on 30 April 2026. Operational risk controls, business continuity, and material service provider identification and monitoring (paragraphs 29, 42 to 45 and 46 to 61)
- Prudential Practice Guide CPG 235 Managing Data RiskAPRA, September 2013. Data risk across the lifecycle, retention, desensitisation, auditability, and outsourcing or offshoring of data management responsibilities
- Scams Prevention Framework Act 2025 (No. 15, 2025)Assented on 20 February 2025 and commenced on 21 February 2025. Inserts Part IVF into the Competition and Consumer Act 2010, with governance, prevention, detection, reporting, disruption and response duties (sections 58BD to 58BZH)
- Scams Prevention Framework Regulated Sectors Designation 2026Registered on 28 May 2026 and commenced on 29 May 2026 (F2026L00627), after being made on 22 May 2026. Designates covered banking services and ASIC as the sector regulator, with transitional provisions that phase obligations to 31 March 2027
- Competition and Consumer (Consumer Data Right) Rules 2020F2020L00094, compilation 1004 of 4 March 2025, read with the Consumer Data Standards version 1.36.0. Data holder obligations, consumer dashboards, and the security steps and minimum information security controls for accredited data recipients and designated gateways
- Privacy Act 1988 and the OAIC APP GuidelinesAustralian Privacy Principle 11 and the Notifiable Data Breaches scheme in Part IIIC. APP 11.3 was added by the Privacy and Other Legislation Amendment Act 2024 and applies to personal information held from 11 December 2024. Chapter 11 of the APP Guidelines was updated on 3 October 2025
Frequently asked questions
Straight answers on coverage, setup, and how results reach your team.
Can't find your answer? Book a demo or contact us.
Test your mobile banking app the way APRA and ASIC describe it
Start with a free scan of your app from the store, or book a demo to run logged-in tests of your app and APIs with our team.