TL;DR: The Bangko Sentral ng Pilipinas has set June 30, 2026, as the deadline for Philippine banks to stop using SMS OTPs for high-risk transactions, while AFASA ties adequate authentication controls to liability protection and requires real-time fraud detection for larger institutions, according to Authsignal. The real shift is that authentication must now be intercept-resistant, layered, and auditable rather than merely available.
At a glance
What this is: This is a regulatory analysis of BSP Circular 1213 and its requirement for Philippine banks to move away from SMS OTPs for high-risk banking activity.
Why it matters: It matters because IAM teams must rework customer authentication, transaction step-up, and fraud controls around intercept-resistant methods that reduce scam exposure and liability risk.
By the numbers:
- Institutions handling complex electronic services, or with average monthly transaction volumes above PHP 75 million, are required to have real-time fraud detection covering behavioral anomalies, geolocation, blacklist screening, and device change events.
- The Bangko Sentral ng Pilipinas has set June 30, 2026, as the deadline for financial institutions to stop using SMS OTPs for high-risk banking transactions.
👉 Read Authsignal's analysis of BSP Circular 1213 and SMS OTP replacement
Context
Philippine banking authentication is moving from a convenience-based model to a transaction-risk model. BSP Circular 1213 requires covered institutions to stop relying on SMS OTPs for high-risk transactions because the factor leaves the bank's control plane and can be intercepted through SIM swap fraud, phishing, or smishing.
That shift matters for IAM because the control objective is no longer just proving presence of a second factor. Banks now need authentication that stays bound to the institution's own trust boundary, can be layered with device and behavioural signals, and can stand up to audit when scam liability is tested.
The article is typical of current financial services guidance: the technical weakness is well understood, but the governance consequence is now formalised by regulation. This is where authentication design, fraud operations, and liability posture converge.
Key questions
Q: What breaks when banks keep using SMS OTP for high-risk transactions?
A: SMS OTP breaks down when the factor can be intercepted, redirected, or socially engineered out of the user. For high-risk banking actions, that means the bank no longer controls the authorisation path end to end. The result is higher fraud exposure and weaker liability protection when scams succeed.
Q: Why do interceptable authentication methods increase scam liability for banks?
A: Because liability now depends on whether the bank used adequate controls, not just whether the customer entered a code. Interceptable methods such as SMS OTP can be defeated outside the bank's trust boundary, which makes them hard to defend as strong authorisation for high-risk activity.
Q: How can security teams know if step-up authentication is actually working?
A: Look for reduced fraud on high-risk transactions, fewer successful account changes after suspicious device or location shifts, and clear evidence that server-side decisions are using multiple signals. If the same risky patterns still lead to approval, the control is not working as intended.
Q: Who is accountable when a bank authorises a scam transaction with weak authentication?
A: Under AFASA and the BSP circular, accountability shifts toward the institution when adequate authentication controls are missing. Banks that fail to put sufficient controls in place may have to reimburse customers directly, so authentication design is now a governance and financial risk issue, not only a security one.
Technical breakdown
Why SMS OTPs fail as a bank-controlled authenticator
SMS OTPs are vulnerable because the secret must travel through telecom infrastructure that the bank does not control. That creates interception paths through SIM swap attacks, phishing pages that harvest codes in real time, and smishing or social engineering that extracts the code from the customer. In IAM terms, the factor is valid only while it remains bound to the intended transaction and channel. Once it can be copied or redirected, it stops being a strong possession factor and becomes a replayable secret.
Practical implication: treat SMS OTP as an auxiliary contact verification method, not a transaction authoriser.
Server-side biometrics and layered step-up authentication
Server-side biometrics validate the user against templates stored in the bank's backend, which keeps the decision inside the institution's control boundary. That is different from device-side biometrics, which only prove that a local device unlocked successfully. The BSP's model also requires liveness detection, encrypted biometric templates, and combination with other controls such as device binding and transaction risk scoring. This is not biometric-only authentication. It is risk-tiered authentication with multiple evidence sources.
Practical implication: design step-up flows so biometric checks are one signal in a broader policy, not the entire control.
Fraud detection becomes part of the authentication control stack
Circular 1213 links authentication change to real-time fraud detection for certain institutions, which is a practical recognition that identity compromise and transaction abuse are now the same operational problem. Behavioural anomalies, geolocation shifts, blacklist checks, and device change events all serve as signals that a transaction may not match the expected account context. In modern IAM, authentication without behavioural context leaves a gap between proving who the user is and proving the transaction is legitimate.
Practical implication: align fraud telemetry with authentication policies so high-risk actions trigger evidence-based step-up or denial.
Threat narrative
Attacker objective: The objective is to bypass transaction authorisation and move funds or alter account details through a code that the victim never truly controlled.
- Entry occurs when attackers use SIM swap fraud, phishing pages, or smishing to obtain the OTP that the bank sent for a high-risk action.
- Escalation follows when the intercepted code is used to authorise account changes, new payees, or large transfers that the customer did not intend.
- Impact is the completion of fraudulent banking transactions with liability now shaped by whether the bank had adequate authentication controls in place.
Breaches seen in the wild
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
- Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
SMS OTP is now a governance liability, not an authentication preference. BSP Circular 1213 moves the discussion away from user convenience and into control ownership. If a bank does not control the channel carrying the factor, it does not fully control the authorisation event. The practitioner conclusion is straightforward: transaction authentication must be evaluated as a risk and liability control, not as an implementation detail.
Interceptable authentication mechanisms create an identity boundary problem. The issue is not that SMS is old technology, but that the factor is designed to leave the bank's trust boundary before the decision is complete. That makes it structurally weaker than controls that keep verification server-side and policy-driven. Banks should read this as a boundary design failure, not just a factor replacement exercise.
Server-side verification changes the locus of trust. When the bank validates the signal in its own backend, it can combine biometrics, device binding, and transaction context into one decision. That is the governance model the circular is pushing toward, and it aligns more closely with NIST SP 800-63 Digital Identity Guidelines and risk-based authentication practice. Practitioners should treat that as a shift in control architecture, not just in authentication UX.
Real-time fraud telemetry is becoming part of identity assurance. The circular recognises that high-risk banking access is no longer separable from transaction monitoring. Behavioural anomalies, blacklist hits, and device-change events are now authentication inputs, which means identity teams and fraud teams need shared operating models. The implication is that banks must manage identity as a continuous risk signal across the transaction lifecycle.
Identity proofing alone does not answer scam liability. AFASA and Circular 1213 together turn weak authentication into a balance-sheet issue. A bank can no longer assume that proving a login event is enough if the transaction path is still interceptable. The practitioner takeaway is that governance, evidence retention, and control design now sit directly in the reimbursement decision path.
From our research:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
- For banks shifting away from SMS OTPs, the next control question is whether authentication and secrets governance are aligned across application, fraud, and identity layers, as explored in the Ultimate Guide to NHIs , The NHI Market.
What this signals
Interceptable authenticator debt: banks that still depend on SMS OTP are carrying a control debt that will show up in fraud losses, audit exceptions, or reimbursement disputes. The useful question for practitioners is not whether to replace SMS, but whether their current step-up model can survive channel interception, device compromise, and social engineering at the same time.
The programme-level shift is toward decisioning that combines identity, device, and transaction context before value-bearing actions are approved. That aligns with phishing-resistant assurance patterns in NIST SP 800-63 Digital Identity Guidelines and with the broader NIST risk-control view captured in NIST SP 800-53 Rev 5 Security and Privacy Controls.
The practical signal to watch is whether fraud and IAM teams share the same policy engine or still operate as separate approval layers. Where those layers stay disconnected, banks often discover too late that a successful login has no meaningful bearing on whether the transaction was legitimate.
For practitioners
- Replace SMS OTP for high-risk flows Move payment authorisation, new payee setup, and registered contact changes to phishing-resistant or server-side authenticated methods. Keep SMS only for narrow verification cases that do not authorise value-bearing actions.
- Map transaction classes to step-up policies Classify banking actions by scam impact and require stronger controls for high-risk transactions, including device binding, biometric checks, and risk scoring before approval.
- Align fraud telemetry with authentication decisions Feed behavioural anomalies, geolocation shifts, blacklist screening, and device-change events into the authentication policy so suspicious activity changes the assurance level in real time.
- Document liability-linked control evidence Retain policy, event, and control logs that show which authenticator was used, which checks passed, and why the bank considered the transaction adequately protected under AFASA.
Key takeaways
- SMS OTP is no longer a defensible authorisation method for high-risk banking activity when the factor can be intercepted outside the bank's control boundary.
- BSP Circular 1213 links authentication design to fraud detection and liability, which makes identity governance part of financial risk management.
- Banks need server-side, layered, and auditable authentication flows that use transaction context, not just a one-time code, to approve sensitive actions.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-63, NIST CSF 2.0, NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) set the technical controls, while GDPR define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | SP 800-63B | The article centres on authenticator strength and phishing resistance. |
| NIST CSF 2.0 | PR.AC-1 | Authentication assurance is the core control issue in this banking mandate. |
| NIST SP 800-53 Rev 5 | IA-2 | User authentication for regulated transactions needs stronger identity proofing and factor management. |
| NIST Zero Trust (SP 800-207) | The circular's control boundary approach aligns with zero trust verification at decision time. | |
| GDPR | Art.32 | Biometric and security processing obligations are relevant where customer identity data is protected. |
Treat biometric processing and authentication logs as security data that require appropriate technical safeguards.
Key terms
- Server-Side Biometrics: An authenticator pattern where the bank verifies biometric evidence against templates stored in its own backend. The control keeps the assurance decision inside the institution's trust boundary, which makes it stronger than device-only checks when the device itself may be compromised.
- Interceptable Authentication Mechanism: Any authentication method that must travel through a channel outside the issuer's direct control before the authorisation decision is complete. In banking, SMS OTP is the clearest example because telecom interception, phishing, and smishing can all break the assurance chain.
- Transaction Risk Scoring: A policy method that adjusts authentication strength according to the value, sensitivity, and context of the action being attempted. It is not a login-only control. It uses device, behavioural, and transaction signals to decide whether a request should proceed, step up, or fail.
What's in the full article
Authsignal's full blog post covers the operational detail this post intentionally leaves for the source:
- Specific guidance on how the circular treats high-risk transactions versus ordinary login activity.
- The distinction between server-side and device-side biometrics for regulated banking flows.
- Implementation notes on layered authentication, liveness checks, and biometric template storage.
- What third-party biometric vendors must provide in due diligence, contracts, and audits.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity and access programme, it is worth exploring.
Published by the NHIMG editorial team on 2026-03-17.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org