BNM’s three card policy documents introduce obligations across three deadline waves. Most Malaysian banks are treating them as three separate procurement tracks. The architecture decision is singular, not sequential.
The architecture decision behind the deadlines
BNM’s card PDs do not create three technology decisions for Malaysian banks. They create one architecture decision.
Malaysian issuers that treat real-time fraud detection, dispute workflow, card-not-present (CNP) authentication, and customer alerts as separate procurement tracks may meet each deadline individually. They will not meet the operating-model test BNM’s supervisor applies across the issuer.
The deadlines look sequential. The decision is singular.
The three policy documents for Debit, Credit, and Charge cards, covering conventional and Islamic variants, were issued by BNM on 19 December 2025. Their obligations land in three waves.
The first wave is already in force. Real-time fraud detection, mandatory kill switch on debit, default CNP and overseas opt-in blocking, and the liability shift provisions all activated immediately. Credit Card PD §26.1(d) sets the new standard: detection must operate in real time. Where losses arise from weaknesses in the issuer’s systems, processes, or controls, cardholder liability may be limited. BNM’s footnote example is unambiguous. A series of transactions within a short time frame, inconsistent with the customer’s normal transaction behavior, left unblocked, becomes the issuer’s exposure.
The second wave landed on 1 April 2026. Issuers now have three working days to acknowledge a card dispute, must issue a written decision, and on debit disputes, must extend provisional credit if investigation runs past 14 working days (RM 5,000 cap), with full disbursement by 30 days.
The third wave arrives on 1 January 2027. Strong customer authentication on every CNP transaction with SMS OTP capped at RM 250, secure device binding by default, cooling-off on new enrollment and contact detail changes, idle CNP re-blocking after 12 months, and expanded customer alerts covering every CNP transaction, every rejected CNP attempt, and every toggle activation.
These three waves usually engage three different internal functions and trigger three separate vendor evaluations. At audit, BNM reads them as one supervisory view.
The procurement trap
What I see consistently across deployments in India, Indonesia, the Philippines, and now Malaysia is a sequential reading of the PDs. Wave one is operational. Wave two is dispute workflow. Wave three is authentication and device. Each wave maps to a different internal function. Each function takes its slice to its preferred vendor.
The result is three procurement tracks running in parallel: three vendor evaluations, three contracts, three integrations, three audit trails reconciling to one supervisory view.
The cost is operational. When fraud detection, dispute investigation, customer alerting, and device intelligence sit on different stacks with different data formats, the bank spends investigator time on data reconciliation, not fraud analysis. An investigator opening a card dispute case routinely pivots through four or five systems before reaching a decision. Under the 3-working-day BNM acknowledgement clock, that pivoting time is the binding constraint, not the investigator’s analytical capability.
The trap is that the procurement decision feels rational at each step. Fraud buys detection. Card buys customer alerting. Risk buys device intelligence. Dispute buys case management. Each function gets what it asked for. The bank gets an architecture that BNM, at audit time, reads as one liability surface with multiple internal seams.
The dual-stack reality in Malaysia
For Malaysian Tier 1s, the procurement trap compounds with the conventional and Islamic banking duality. Most run parallel cards businesses across a conventional book and an Islamic subsidiary, often on different cards processors, with different rule sets, different investigation workflows, and different reporting lines into BNMLINK. Shariah governance overlays add an approval cycle to every rule change on the Islamic side.
From a technology-purchase view, this looks like two separate engagements. The conventional bank evaluates one stack, the Islamic subsidiary another. Vendors quote separately, deploy separately, run separate roadmaps.
From BNM’s supervisory view, it is one issuer-wide exposure. The 3-working-day dispute acknowledgement clock runs on the slowest side. The behavioral baseline asked for in audit has to be assemblable across both books. The customer alert channel cannot fragment per book if the customer holds cards across both.
This is not a Shariah question but an architecture one. Islamic-side governance can be preserved with one platform and dual-rule-policy management. Banks that try to preserve it by buying two platforms end up paying twice for the same compliance capability and running twice the integration work.
What integrated looks like
The architecture that holds across all three BNM card PD waves runs four functional layers on one platform.
- The detection layer operates pre-authorization. Every card transaction is scored in real time against behavioral baselines built from device, location, network, and transaction signals. Rules catch known patterns. Machine learning surfaces anomalies and behavior drift. The detection layer addresses Wave 1 and produces the evidence trail the dispute desk later relies on.
- The decide-and-investigate layer is the case management workflow. It opens a case file with detection rationale, customer history, and device evidence pre-assembled. The 14 and 30 working-day debit provisional credit triggers operate automatically. Generative AI investigator support compresses case investigation time, which is where post-April 2026 dispute volume math becomes tractable. This layer addresses Wave 2.
- The inform-customer layer handles transaction alerts and customer notifications across SMS, in-app, and voice channels. BNM’s anti-phishing constraints (no hyperlinks, no callback numbers) are built into the alerting template. The layer scales to Wave 3’s expanded scope.
- The learn-and-adapt layer feeds detection rules with channel-level intelligence the other layers cannot see. Voice analytics on call-center intake surfaces social engineering coaching patterns and mule recruitment scripts before they appear in transaction data. These patterns become new detection rules in the detection layer, closing the loop. This is what continuous improvement looks like under the BNM standard, and it is what allows the detection layer to keep pace with fraud typology drift between PD reviews.
That is one audit trail end-to-end. The same architecture handles the conventional book and the Islamic book under one operational model, with Shariah governance preserved at the rule-policy level rather than at the platform level.
The three BNM card PD deadlines are sequential. The architecture decision that meets them is singular. Banks scoping it as one platform decision will be in compliance position when the third deadline lands. Banks buying in three pieces will spend the next twelve months reconciling vendors instead of investigating fraud.
The deadlines are the regulator’s design. The operating model that meets them is the bank’s responsibility. Integrated platform thinking is how that operating model gets built.
Approach BNM card PD compliance as one platform decision with Clari5
The architecture described in this article is one Clari5 has built, deployed, and refined across Indian, APAC, and MENA banks, including environments running parallel conventional and Islamic banking books on different cores. Request a conversation with our solution team →
