Skip to main content
Australian Prudential Regulation Authority

APRA authentication and app-security requirements.

How financial institutions in Australia meet them with Fortanixor — banks, exchange houses, payment providers, microfinance and fintechs supervised by the Australian Prudential Regulation Authority.

Regulation refs: APRA Prudential Standard CPS 234 Information Security (July 2019); APRA Prudential Practice Guide CPG 234 Information Security (June 2019); APRA letter: Use of multi-factor authentication (MFA) (26 May 2023); APRA Prudential Standard CPS 230 Operational Risk Management (version commencing 1 July 2026); APRA Letter to Industry on Artificial Intelligence (30 April 2026); Scams Prevention Framework Act 2025 and the SPF Regulated Sectors Designation 2026; ASIC ePayments Code (effective 2 June 2022); Privacy Act 1988 — Australian Privacy Principles (OAIC)

Australia regulates authentication by principle rather than by mechanism, and the principle has teeth. APRA, the prudential regulator for banks, binds every ADI to paragraph 21 of CPS 234 Information Security: controls must be commensurate with the threats, the criticality and sensitivity of the information assets, and the consequences of an incident. CPG 234 then spells out where that bites hardest — increased authentication strength for high-risk activities such as third-party fund transfers and the creation of new payees, and multi-factor authentication for those activities. APRA's May 2023 letter on MFA closed the loop. It named the gaps APRA had found in supervision, including MFA for customers offered only on an opt-in basis and exceptions for customers without mobile phones or reliable phone reception. It also said that where an MFA coverage gap could materially affect customers, APRA would treat it as a material control weakness, notifiable under paragraph 36 of CPS 234. APRA does not ban SMS one-time codes, but it has made the weaknesses of an SMS-dependent rollout a reporting matter.

Three newer instruments sit around that core. The Scams Prevention Framework Act 2025 requires banks to take reasonable steps to prevent, detect and disrupt scams, including scams that impersonate the bank. The Regulated Sectors Designation 2026 brings ADIs into scope with ASIC as their sector regulator, and the transitional provisions mean those principles bind banks from 31 March 2027. CPS 230 Operational Risk Management makes customer enquiries a critical operation for every APRA-regulated entity, and requires APRA to be notified before any material offshoring arrangement. And APRA's April 2026 letter on AI expects credible fallback where AI supports a critical operation, human involvement in high-risk decisions, and tested exit and substitution plans for critical AI providers. The Reserve Bank of Australia is the central bank, not the banks' prudential or conduct supervisor, so nothing on this page is attributed to it.

What Australian Prudential Regulation Authority requires

01 / 06

Authentication strength commensurate with the impact of a falsified identity

CPS 234 requires information security controls commensurate with vulnerabilities and threats, the criticality and sensitivity of the information assets, and the potential consequences of an incident. CPG 234 explains how APRA reads that for authentication. Strength should match the impact if an identity is falsified, and increased strength is typically required for high-risk activities such as third-party fund transfers and the creation of new payees. The guide lists multi-factor authentication for privileged access, remote access and other high-risk activities among the controls an entity would typically deploy, and names cryptographic techniques as a way to strengthen authentication. CPG 234 is guidance; the binding obligation is paragraph 21.

CPS 234, paragraph 21; CPG 234, Attachment C, paragraphs 5, 6 and 7(j)

02 / 06

MFA coverage gaps are a notifiable control weakness

APRA's May 2023 letter to all regulated entities says MFA is one of the most effective controls against unauthorised access and expects entities to review its coverage. It names the gaps found in supervision: customer MFA offered only on an opt-in basis, exceptions for customers without mobile phones or reliable phone reception, and third-party staff given remote access without MFA. Where a coverage gap could materially affect the entity or its customers, APRA would consider it a material security control weakness, notifiable within 10 business days under paragraph 36 of CPS 234 if the entity does not expect to remediate it in a timely manner.

APRA letter, Use of multi-factor authentication (MFA), 26 May 2023; CPS 234, paragraph 36

03 / 06

Customer security on digital channels

For products and services delivered through digital channels, CPG 234 lists common controls. These include authentication controls commensurate with the threats, which could include a second-channel notification or confirmation of events such as account transfers, new payees, change of address and access from an unrecognised device. They also include transaction activity monitoring to detect unusual patterns, and minimising the collection of sensitive customer information, including information used for authentication such as passwords and PINs. Attachment C adds that passwords and PINs used to authorise high-risk activities should be generated rather than stored.

CPG 234, Attachment F, paragraph 1(a), 1(c) and 1(e); Attachment C, paragraph 7(k)

04 / 06

Service providers, critical operations and offshoring

Where a third party manages an entity's information assets, CPS 234 requires the entity to assess that party's information security capability and evaluate the design of its controls. CPS 230 goes further for material service providers. They must be on a register; the entity must do due diligence that weighs geographic location and concentration risk; and the formal agreement must give APRA access to documentation and data and a right to visit the provider on site. The entity must also be able to exit the arrangement in an orderly way. Customer enquiries are a minimum critical operation for every APRA-regulated entity, with tolerance levels for disruption. APRA must be notified before any material offshoring arrangement, including where data or personnel relevant to the service will be located offshore.

CPS 234, paragraphs 16 and 22; CPS 230, paragraphs 35(d), 37, 48, 52 to 55 and 60

05 / 06

Reasonable steps to prevent, detect and disrupt scams

Under the Scams Prevention Framework a regulated entity must take reasonable steps to prevent another person from committing a scam using its services. It must also detect scams as they happen and after they happen, and act within a reasonable time on actionable scam intelligence to disrupt the activity and prevent further loss. Each is a civil penalty provision. A scam includes an attempt that impersonates the regulated entity. Services provided by an ADI in carrying on its banking business are designated, with ASIC as the sector regulator. Transitional provisions defer these principles for banks until 31 March 2027, and the banking sector code that will detail reasonable steps has not yet been made.

Competition and Consumer Act 2010, sections 58AG, 58BJ, 58BM and 58BX (inserted by the Scams Prevention Framework Act 2025); Regulated Sectors Designation 2026, sections 11, 12 and 101

06 / 06

AI risk governance and privacy in automated customer interactions

APRA's April 2026 letter requires entities to manage AI risk: set a risk appetite, keep an inventory of AI tools and use cases, keep humans involved in high-risk decisions, control agentic and autonomous workflows, and monitor continuously. Where AI supports a critical operation, credible fallback processes are required. Supplier arrangements should give transparency, auditability and assurance, with credible substitution or exit plans for critical AI providers. Under the Privacy Act, an entity must take reasonable steps to protect the personal information it holds and remains accountable when it discloses that information overseas. OAIC guidance adds that public-facing AI tools should be clearly identified as such to users.

APRA Letter to Industry on Artificial Intelligence, 30 April 2026; Australian Privacy Principles 8.1 and 11.1; OAIC Guidance on privacy and the use of commercially available AI products

Control mapping

How Fortanixor maps to APRA requirements.
RequirementFramework referenceHow Fortanixor addresses itProduct
Increased authentication strength and MFA for high-risk activities such as third-party fund transfers and new payeesCPG 234, Attachment C, paragraphs 6(c) and 7(j); CPS 234, paragraph 21A FIDO2 passkey gives two factors in one gesture: possession of the device holding the private key, and the biometric or PIN that unlocks it in the secure element. The same ceremony can be required as a step-up on each high-risk activity CPG 234 names, such as adding a payee or making a third-party transfer. Because the credential is a cryptographic key, it uses the cryptographic techniques Attachment C lists for strengthening authentication.FortAuth
Closing the MFA coverage gaps APRA named: opt-in customer MFA and exceptions for customers without reliable phone receptionAPRA letter, Use of multi-factor authentication (MFA), 26 May 2023; CPS 234, paragraph 36A passkey ceremony runs on the customer's own device and does not wait for a text message, so poor phone reception stops being a reason to exempt a customer from MFA. Because enrolment adds no step at sign-in, the bank can make MFA the default rather than opt-in. For customers without a mobile phone, the bank still needs its own alternative path; the letter expects that path to be assessed for coverage rather than waived.FortAuth
Second-channel notification or confirmation of account transfers, new payees, change of address and access from an unrecognised deviceCPG 234, Attachment F, paragraph 1(a)With Secure Payment Confirmation, the amount and payee are shown to the customer and bound into the signed data, so the confirmation is evidenced by a signature rather than by a code that could be relayed. When a customer gives an instruction by voice, FortVoice transcribes it and has the customer confirm it on the phone before it executes, so a spoken command never moves money on its own.FortAuthFortVoice
Minimising the authentication information collected and held, with secrets generated rather than storedCPG 234, Attachment F, paragraph 1(e); Attachment C, paragraph 7(k)The bank holds only the passkey's public key. The private key is generated inside the device's secure element and cannot be exported, and the biometric never leaves the device. For the passkey path there is no password, PIN or one-time code for the bank to collect, store or lose in a breach.FortAuth
Evidence on whether a transaction was authorised, where a correct device or passcode is not of itself proofASIC ePayments Code, clauses 11.8(b) and 11.9(b)Under clause 11.8(b), access with the correct device or passcode does not on its own prove the user contributed to a loss, and clause 11.9(b) looks at how secure and reliable the subscriber's method of verifying authorisation was. Each passkey approval is a signature from a key that exists only on the customer's device, logged with its result. With Secure Payment Confirmation it covers the specific amount and payee. That is stronger evidence of what the customer approved than a record that a code was sent. It does not change how the Code allocates liability. The Code is voluntary and binds its subscribers.FortAuth
Material offshoring notified to APRA in advance, and cross-border disclosure of personal informationCPS 230, paragraphs 52(b) and 60(b), footnote 16; Australian Privacy Principle 8.1All three products deploy on-premise, into Australian-region cloud, or hybrid. Authentication records, speech processing and call transcripts can then stay in Australia, so the data does not go overseas in a way that would engage APP 8.1. FortVoice processes speech in the bank's own region rather than sending audio to a global endpoint. One fact is stated plainly: Fortanixor's offices are in the UAE and Pakistan, and paragraph 60(b) names offshore personnel as well as offshore data. Whether support from those offices makes the arrangement a material offshoring arrangement is for the bank to assess.FortAuthFortVoiceFortAgent
Customer enquiries maintained as a critical operation within tolerance, with a credible fallback where AI supports itCPS 230, paragraphs 35(d), 37 and 55(d); APRA Letter to Industry on Artificial Intelligence, 30 April 2026FortAgent can hand any call to a person at any point, which gives the bank its fallback when the AI channel is degraded. Because FortAgent is model agnostic, the bank can substitute the underlying model without rebuilding the contact-centre flows. That supports both the exit requirement in CPS 230 paragraph 55(d) and the substitution and exit planning for critical AI providers that APRA's AI letter found few entities had tested.FortAgent
Reasonable steps to prevent and detect scams, including scams that impersonate the bankCompetition and Consumer Act 2010, sections 58AG(2)(b), 58BJ and 58BM (Scams Prevention Framework Act 2025)A passkey only works on the bank's genuine domain or app, so a lookalike site impersonating the bank cannot collect a credential or a code to replay. On the phone, FortAgent verifies the caller through FortAuth on their own device before any account action, rather than relying on knowledge-based questions. Every call is transcribed and scored, which gives the bank a record it can review to detect a scam after it happens. These principles bind banks from 31 March 2027, and the banking code that will set out reasonable steps has not been made yet.FortAuthFortAgent
AI governance: inventory, human involvement in high-risk decisions, continuous monitoring, and supplier transparency and auditabilityAPRA Letter to Industry on Artificial Intelligence, 30 April 2026Every FortAgent call is transcribed, QA-scored and summarised with a full audit trail. That gives the bank the continuous, per-interaction monitoring the letter asks for, in place of the point-in-time sampling it criticises. Agent actions run under allow-listed tools and policy controls, and a person can take over at any point, which keeps human involvement where the bank classes a decision as high-risk. In-region or on-premise deployment lets the bank's own second line and internal audit examine the system directly.FortAgent
AI tools identified to customers, and privacy-policy transparency about automated decisions from 10 December 2026OAIC Guidance on privacy and the use of commercially available AI products (Transparency); Australian Privacy Principles 1.7 to 1.9, as described in the OAIC fact sheet of September 2026FortAgent tells every caller they are speaking to an AI agent. The OAIC expects vendors to give clear, high-level information about how their software can be used to make decisions, so Fortanixor documents what FortAgent decides alone and what it only prepares for a person. The bank can then describe those decisions in its APP 1 privacy policy. Whether a given FortAgent use falls within APP 1.7 is the bank's assessment.FortAgent
What this mapping does not claim

Where a requirement belongs to the bank’s own operations, or where the regulator has published no rule to map to, we say so rather than stretch a row to cover it. This is the boundary of the table above, not a gap in it.

  • Board accountability, information security roles, policy framework and internal auditCPS 234, paragraphs 13 to 19 and 32 to 34. These are governance obligations of the ADI's Board, senior management and internal audit function. A vendor cannot discharge them.
  • Notifying APRA of incidents, control weaknesses and critical-operation disruptionsCPS 234, paragraphs 35 (72 hours) and 36 (10 business days); CPS 230, paragraphs 32, 41 and 60(a). Our ceremony logs and call transcripts help the bank establish facts quickly. The determination and the filing remain the bank's.
  • Scams Prevention Framework governance, reporting and dispute resolutionCompetition and Consumer Act 2010, sections 58BD to 58BF (governance policies, annual senior-officer certification, six-year records), 58BR and 58BS (reporting to SPF regulators), 58BZC and 58BZD (reporting mechanism and internal dispute resolution) and 58BZG (AFCA membership, required of banks from 1 September 2026). These are the bank's programme. Our products supply controls and evidence; they are not the programme.
  • The SPF banking sector codeNot yet made. ASIC states that the SPF codes and rules are being developed by Government and that Treasury has consulted on a draft banking sector code. No mapping on this page relies on a code provision, and the rows will be re-read against the code once it is made.
  • Data residency for customer or transaction dataNot established. CPS 234 and CPS 230 were read in full and neither requires data to be held in Australia. CPS 230 paragraph 60(b) requires prior notification of material offshoring, not a prohibition, and APP 8.1 is an accountability rule for overseas disclosure, not a localisation rule. No residency claim is made for Australia.
  • Consent and notice rules for recording customer callsNot established. Commonwealth interception law and the state and territory surveillance and listening devices Acts were not read for this page. FortAgent records and transcribes calls; the bank's call notice and consent wording remains the bank's, and we make no claim about what those laws require.
  • A statutory AI-disclosure obligationNot established. Neither APRA's April 2026 AI letter nor CPS 234, CPG 234 or CPS 230 contains an obligation to tell customers they are dealing with AI. The only official statement found is the OAIC's guidance that public-facing AI tools should be clearly identified, which is guidance, not a statutory rule. FortAgent discloses regardless; we do not claim Australian law requires it.
Sources

Every clause cited on this page was read in the document below, on the regulator’s own site.

This mapping is provided for guidance and must be validated by the bank's compliance function against the current version of each framework.

Deployment options in Australia

Served from our UAE and Pakistan offices, with deployment on-premise, in Australian-region cloud, or hybrid.

Deployment shapes

On-premiseIn-region cloudHybrid

Runs on

Amazon Web ServicesMicrosoft AzureGoogle Cloud

Deployed into your own account and your own region on any of the three, or on-premise where the data must not leave your estate at all.

APRA questions, answered.

APRA does not name a mechanism, so this is a mapping, not a mandate. CPS 234 paragraph 21 requires controls commensurate with the threat and the sensitivity of the assets. CPG 234 Attachment C says authentication strength should match the impact of a falsified identity, and lists MFA for high-risk activities such as third-party transfers and new payees. APRA's May 2023 letter says effective MFA must use at least two elements: something the person knows, has or is. A FIDO2 passkey supplies two in one gesture, possession of the device-bound key and the biometric or PIN that unlocks it, and it is the kind of cryptographic technique CPG 234 lists for strengthening authentication. CPG 234 is guidance rather than an enforceable standard, so validate the mapping against the current version of each document.

Yes, as a deployment choice. All three products run on-premise, in Australian-region cloud, or hybrid, so authentication records, speech processing and call transcripts can stay onshore. On the regulatory position, neither CPS 234 nor CPS 230 requires data to be held in Australia. CPS 230 paragraph 60(b) does require you to notify APRA before entering a material offshoring arrangement, including where data or personnel will be offshore. Fortanixor's offices are in the UAE and Pakistan, so if you classify us as a material service provider, assess how our support arrangements bear on that paragraph. This is a capability we offer, not a residency rule we are meeting.

It can, but APRA does not require it. The May 2023 letter treats a phone used to generate a one-time code as a valid factor. What it criticises is the shape of SMS-dependent rollouts: customer MFA offered only as opt-in, and exceptions for customers without mobile phones or reliable reception. Where such a gap could materially affect customers, APRA treats it as a notifiable control weakness. Passkeys remove the reception dependency and make default-on MFA practical. Banks here typically enrol passkeys alongside the existing OTP, move sign-in and payee creation first, keep an assessed fallback for customers who cannot use a passkey, and retire the SMS path once enrolment is high enough.

It cites APRA's own paragraph numbering, links to the standard, the guide and the letter on APRA's site, and separates what the product does from what stays with the bank. The downloadable APRA mapping covers CPS 234 paragraphs 21 and 36, CPG 234 Attachments C and F, the CPS 230 service-provider and critical-operations paragraphs, and the Scams Prevention Framework's prevent, detect and disrupt principles. It names what is outside our scope: Board accountability, APRA notifications, the SPF governance and dispute-resolution programme, call-recording consent, and the banking sector code, which has not yet been made. It also flags what is not yet in force: the SPF principles bind banks from 31 March 2027, and the APP 1.7 automated-decision transparency obligation applies from 10 December 2026.

Get the APRA control mapping

The full control-by-control mapping for FortAuth, FortVoice and FortAgent, as a document your compliance function can review.

Other markets