Allianz Malaysia Berhad

Market position: #1 General Insurer by gross written premium. Publicly listed on Bursa Malaysia. Subsidiary of Allianz SE, Germany. Offers both general and life insurance. BNM regulated under FSA 2013.

Architectural significance: Allianz Malaysia operates at the highest policy volume of any Malaysian general insurer, meaning its core policy administration system must handle peak endorsement and renewal loads that would stress any legacy monolith. Its legacy system landscape includes a mix of locally customised Allianz Group platforms and inherited Malaysian on-premise PAS systems, creating a hybrid that is expensive to maintain and difficult to extend with modern API capabilities. An EA joining Allianz faces a modernization challenge defined by group-mandated global standards that may conflict with local regulatory requirements — navigating between Allianz SE's enterprise architecture governance and BNM's data localisation and product filing rules demands simultaneous fluency in group IT governance and Malaysian insurance regulation.

Etiqa Insurance & Takaful

Market position: Top 3 general and Takaful insurer. Wholly owned by Maybank. Covers general, life, and takaful. Dominant bancassurance position via Maybank branch network. BNM regulated under FSA 2013 and IFSA 2013.

Architectural significance: Etiqa's architectural significance stems from its deep bancassurance integration with Maybank — its single most important distribution channel — which requires real-time policy issuance APIs that must perform within the latency tolerance of a banking digital platform serving millions of customers. Its legacy landscape spans both conventional insurance and takaful systems, often running on separate platforms with separate data models, creating a dual-system complexity that is rare among peers. An EA at Etiqa must manage the intersection of two regulatory regimes — FSA 2013 for conventional and IFSA 2013 for takaful — and must design an integration architecture that satisfies both while enabling a unified bancassurance product experience for Maybank customers.

AIA Malaysia

Market position: #1 Life Insurer in Malaysia, growing general insurance presence. Subsidiary of AIA Group, Hong Kong. Extensive tied agent network. Covers life, health, and general insurance. BNM regulated.

Architectural significance: AIA Malaysia is architecturally significant in the general insurance context because it is growing its general lines portfolio on top of a mature life insurance technology estate — meaning general insurance capabilities must be layered onto a platform heritage never designed for high-frequency motor underwriting. Its legacy landscape is anchored in AIA Group's regional platforms, which are life-centric and require significant adaptation to support the volume-driven motor and general insurance workflows that BNM and ISM compliance demands. An EA joining AIA faces the challenge of extending a life-insurance-optimised architecture to support general insurance STP issuance, NCD management, and claims TAT tracking without disrupting the core life business that dominates the organisation's revenue and executive attention.

Zurich General Insurance Malaysia

Market position: Top 5 general insurer. Subsidiary of Zurich Group, Switzerland. Strong commercial and SME presence. Lines include motor, property, liability, and marine. BNM regulated.

Architectural significance: Zurich General Insurance Malaysia is architecturally significant for its combination of high-complexity commercial lines — property, liability, marine — alongside a substantial motor portfolio, requiring underwriting systems that can handle both simple motor rating and complex multi-risk commercial submissions. Its legacy landscape reflects the Zurich Group's global platform strategy, which historically favoured regional shared services over country-specific deployments, creating a dependency on offshore systems for core policy functions that introduces data sovereignty and latency challenges under BNM's data localisation framework. An EA at Zurich faces a modernization challenge shaped by the need to balance group IT mandates from Zurich's global architecture team with the requirement to localise critical systems and reporting pipelines to satisfy BNM supervisory obligations.

Tokio Marine Insurance Malaysia

Market position: Top 5 general insurer. Subsidiary of Tokio Marine Group, Japan. Established in Malaysia in 1975. Lines include motor, fire, marine, and liability. BNM regulated.

Architectural significance: Tokio Marine's architectural significance lies in its long operating history in Malaysia — established in 1975 — which means its core systems carry five decades of accumulated insurance business logic, product rules, and claims workflow customisation that is deeply embedded and difficult to untangle. Its legacy landscape is characterised by Japanese-parent-influenced on-premise systems built for stability and longevity rather than agility, with significant manual workarounds developed over decades to compensate for integration gaps that were never formally addressed. An EA joining Tokio Marine faces a modernization challenge that is as much about organisational change as technology: long-tenured staff who own institutional knowledge of the legacy system, a parent company in Japan with its own technology governance expectations, and a BNM regulatory environment that has materially accelerated its digital expectations since the legacy systems were last substantially refreshed.

Underwriting

Underwriting is the revenue-generating core of a general insurer — the function that assesses, prices, and accepts risk. In a Malaysian motor context, this means evaluating millions of vehicle risks each year against a tariff structure set by ISM, applying NCD entitlements fetched from the ISM NCD database, and deciding whether to accept, decline, or refer a risk to a senior underwriter. Motor Lines alone can process upward of 50,000 vehicle endorsements per month. General Lines underwrites non-motor risks including commercial fire policies for SMEs, marine cargo, personal accident covers, and public liability policies, each with different rating factors, exclusions, and reinsurance treatment. Reinsurance manages the treaty arrangements that protect the insurer's net retained position — quarterly cession statements must be prepared, monthly bordereau submitted to treaty reinsurers, and facultative placements managed for risks that exceed treaty capacity.

Sub-units and day-to-day examples: Motor Lines processes 50,000+ vehicle endorsements per month and calculates NCD discounts (0%–55%) using real-time ISM NCD lookup. General Lines underwrites a RM 20M commercial fire policy for a manufacturing facility, referring to Head of UW for approval. Reinsurance submits monthly motor bordereau to quota share treaty reinsurer and places facultative reinsurance for a RM 150M petrochemical plant fire risk. EA relevance: Underwriting is the primary business stakeholder for the Guidewire PolicyCenter implementation — the rules engine, rating configuration, and product model are owned by Underwriting, and any architecture decision affecting policy lifecycle must be validated against their operational requirements.

Claims

Claims is the largest operational cost centre in a general insurer and the function most directly exposed to BNM's TAT regulatory obligations. BNM requires that straightforward motor claims be acknowledged within 7 days of notification and settled within 30 days — failure to comply results in regulatory enforcement action. In a high-volume motor insurer, Claims Assessment receives hundreds of new motor claims each week — each requiring coverage verification, liability assessment, quantum estimation, and adjuster assignment. Claims Settlement processes approved payments either directly to policyholders or to panel workshops. Fraud Investigation is a critical sub-unit — motor fraud in Malaysia includes staged accidents, inflated repair invoices, phantom passengers, and cross-industry fraud networks.

Sub-units and day-to-day examples: Claims Assessment receives 200 new motor claims on Monday morning, auto-triages 60% as low-value desk assessments, assigns 40% to panel adjusters within 24 hours. Claims Settlement processes panel workshop invoice for RM 8,500 bumper repair; issues payment within 14 days of assessment completion. Fraud Investigation investigates staged accident claim — three separate claimants submitting from same workshop within 48 hours; cross-references IFBM fraud database. EA relevance: Claims is the primary stakeholder for Guidewire ClaimCenter — the FNOL workflow, adjuster assignment rules, TAT monitoring dashboards, and fraud scoring API integration are all governed by Claims operational requirements.

Sales & Distribution

Sales & Distribution owns the channels through which insurance products reach customers — in Malaysian general insurance, dominated by three channels: tied agents and brokers (majority of motor and general premium), bancassurance partnerships with banks (who bundle insurance with loan products), and direct sales through walk-in, telesales, and digital channels. Agent management includes licensing verification (BNM requires all agents to be registered under the Financial Advisers Act), commission management, and productivity tracking. Bancassurance requires real-time product APIs that return quotes and bind policies within the latency tolerance of a bank's digital platform.

Sub-units and day-to-day examples: Agent/Broker Network manages 1,200 active tied agents; processes broker-submitted commercial fire risk; calculates and pays monthly commission statements via Oracle payroll integration. Direct Sales handles 80 motor renewal quotes per day per call centre agent; online portal handles 300 self-service motor renewals per weekend. Bancassurance provides real-time motor quote API to bank's mobile app — must respond within 800ms; processes 5,000 motor policies per month sold through bank branch network. EA relevance: Distribution channels directly determine the API surface that must be built — each channel is a consumer of the Experience API layer in the MuleSoft architecture, with different payload requirements, authentication patterns, and performance expectations.

Actuarial & Risk

Actuarial & Risk prices the business, reserves for future claims, and quantifies the enterprise risk position. Pricing uses ISM's industry loss statistics, internal claims experience, and competitive market data to set tariff rates filed with BNM before implementation. Reserving calculates IBNR and IBNER reserves that must be accurate enough to satisfy the appointed actuary's annual sign-off and BNM's statutory capital requirements. Enterprise Risk runs the Internal Capital Adequacy Assessment Process (ICAAP) mandated by BNM's Risk-Based Capital framework.

Sub-units and day-to-day examples: Pricing analyses 3 years of motor claims data to justify a 12% premium increase for young drivers under 25 — files revised tariff with BNM via actuarial justification report. Reserving calculates RM 45M IBNR reserve for motor claims at Q3 close; reconciles to claims ledger in Oracle; appointed actuary reviews and signs off for BNM submission. Enterprise Risk models 1-in-200-year flood scenario for Klang Valley property portfolio; calculates PML; determines reinsurance purchasing strategy for next treaty year. EA relevance: Actuarial & Risk is both a data consumer and a data quality enforcer — MG-ALFA draws pricing inputs from Snowflake, and its outputs feed the Guidewire PolicyCenter rating engine, making the data pipeline between these three systems architecturally critical.

Finance & Compliance

Finance & Compliance is merged as a single function because in a BNM-regulated insurer, the line between financial management and regulatory compliance is structurally blurred — the CFO is simultaneously responsible for the accuracy of the audited financial statements and the completeness of BNM statutory returns, both of which draw from the same underlying premium and claims accounting data. Accounting manages the premium ledger, claims ledger, and reinsurance accounting ledger. BNM Regulatory Compliance manages the submission calendar for all BNM periodic returns. Internal Audit provides independent assurance over all of the above.

Sub-units and day-to-day examples: Accounting reconciles RM 12M of motor premium received in October against PolicyCenter policy records and payment gateway receipts; posts to Oracle GL. BNM Regulatory Compliance prepares quarterly BNM Jadual 6 statistical return — motor premium by class, claims paid, outstanding reserves — submitted via BNM's FAST reporting portal. Internal Audit audits a sample of 200 motor claims settled in Q2 — verifies adjuster appointment within TAT, repair invoice verification, and payment accuracy. EA relevance: This function is the primary consumer of the Snowflake regulatory reporting pipeline — all BNM submissions must flow through Snowflake to ensure reconciliation against source systems, and the Oracle Financials integration must be designed to the precision standards that a statutory audit demands.

Operations & IT

Operations & IT is elevated — not subordinated — because motor insurance at scale is fundamentally an operations business: hundreds of thousands of policies, endorsements, and claims processed each year require industrial-strength operations management and the IT systems to support them. Policy Administration owns issuance, endorsement, renewal, and cancellation of every policy in the portfolio. Customer Service handles policyholder inquiries and complaints within BNM-mandated TAT. IT Systems & Architecture owns the core platform, legacy modernization program, API integration standards, and multi-squad delivery governance. Process & Quality manages SOPs, process re-engineering, and QA across all delivery squads.

Sub-units and day-to-day examples: Policy Administration processes 2,000 motor renewals per day during peak season using PolicyCenter STP workflow. Customer Service handles 150 policyholder calls per day; logs all complaints in Salesforce; escalates any BNM TAT-approaching complaint to senior management. IT Systems & Architecture chairs the ARB monthly and the ADA fortnightly; reviews all integration design proposals before implementation. Process & Quality conducts quarterly SLA reviews across all delivery squads and publishes the process improvement register. EA relevance: This is the organisational home of the Enterprise Architect — the function that owns both the systems and the operational outcomes, making it the structural precondition for an EA to have genuine authority in a multi-squad delivery model.

Customer & Growth — Digital-First Distribution

Replaces traditional Sales & Distribution. Owns the digital acquisition funnel, omnichannel customer experience, and data-driven retention — capabilities that traditional structures do not recognise as a distinct function. Governs the Salesforce Financial Services Cloud platform, the Customer Portal Experience API, and the aggregator integration layer.

Systems governed: Salesforce FSC (customer 360, renewal campaigns, complaint tracking), MuleSoft Customer Portal Experience API, MuleSoft Aggregator Experience API, AWS S3 (policy document delivery), SageMaker retention propensity model outputs. Problems solved: Without this function, digital channel investments become ownership-less projects that no operating unit has accountability for maintaining or evolving after go-live. What breaks if missing: The organisation defaults to agent-led distribution with no strategic investment in the direct and digital channels that BNM expects insurers to develop for greater consumer access. Lapse rates climb above 15–20% with no data-driven retention capability to intervene.

Data & AI — Top-Level Data Ownership

Not buried under Technology. Owns the Snowflake data platform, the AWS SageMaker AI and ML model registry, and the analytics products consumed by every other function — pricing models for Underwriting, fraud scores for Claims, retention propensity for Customer & Growth, and regulatory reporting datasets for Finance & Compliance.

Systems governed: Snowflake (all data domain schemas, data contracts, access policies, regulatory reporting transformations), SageMaker (model training pipelines, deployment endpoints, model monitoring and retraining schedules), data ingestion pipelines from PolicyCenter, ClaimCenter, Salesforce, and Oracle. Problems solved: Provides a single source of truth for all regulatory submissions, eliminating manual compilation risk. Provides governed training data for AI models. What breaks if missing: Without this function at the top level, data governance becomes a cross-functional coordination problem with no owner. AI models are deployed without governance. Regulatory reporting remains a manual extraction exercise from multiple inconsistent source systems — a BNM audit risk that has resulted in enforcement action at peer institutions.

Technology & Operations — Digital Backbone

Owns the Guidewire Cloud platform engineering, the AWS cloud infrastructure and DevOps pipelines, the MuleSoft Anypoint API and integration layer, and the ARB/ADA governance process. This function's defining characteristic compared to a traditional IT function is that it owns outcomes, not just systems: platform reliability SLAs, API availability metrics, deployment velocity, and integration test coverage are all accountability points.

Systems governed: Guidewire PolicyCenter and ClaimCenter Cloud (platform engineering, configuration releases, quarterly cloud updates), AWS EKS/EventBridge/S3/CloudWatch (cloud infrastructure and DevOps), MuleSoft Anypoint Platform (API governance, consumer onboarding, integration standards), ARB/ADA governance forums (architecture decision records, design authority). Problems solved: Also owns the coexistence architecture during the strangler fig migration — the System API anti-corruption layer that shields consumers from the legacy-to-modern transition. What breaks if missing: API governance collapses into a project-by-project decision. Cloud infrastructure is managed reactively. The multi-squad delivery model loses its technical governance anchor — an EA without this function has no organisational home from which to enforce architecture standards.

Customer Management

Customer Management covers the full lifecycle of the insurer's relationship with its policyholders — from first contact through to retention and complaint resolution. In Malaysian general and motor insurance, this domain is particularly important because motor policyholders are highly price-sensitive and have low switching costs: an insurer that cannot deliver a fast, frictionless renewal experience will see motor lapse rates climb above 15–20%. BNM's market conduct guidelines impose TAT obligations on complaint handling (acknowledgement within 5 business days, resolution within 14 days), making Customer Servicing a compliance domain as well as a customer experience one. KYC & Verification is regulated under BNM's AML/CFT guidelines — every new policyholder must be screened against sanctions lists and politically exposed persons (PEP) databases before a policy is bound.

Sub-capabilities with examples: Customer Acquisition — aggregator-referred motor prospect completes quote-to-bind online in under 3 minutes. Customer Onboarding — new policyholder identity verified via MyKad API; policy schedule emailed within 60 seconds of payment. Customer Retention — SageMaker propensity model flags 8,000 high-lapse-risk renewals; targeted WhatsApp campaign sent 45 days before expiry. Customer Servicing — policyholder adds named driver via self-service portal; endorsement processed in PolicyCenter within 2 minutes. Complaints Handling — complaint received on Monday; acknowledged Tuesday; root cause investigated and resolved within 10 business days; BNM TAT met. KYC & Verification — new commercial property policyholder screened against UN sanctions list; clear result recorded in Salesforce before policy bound.

Product Management

Product Management defines what insurance products the company offers, how they are priced, and how they are approved and launched. In Malaysia, all general insurance products must be filed with and approved by BNM before sale — a product that is sold without BNM approval, or sold with terms that deviate from the approved filing, constitutes a regulatory breach. Tariff Management is a sub-capability unique to the Malaysian motor market: ISM publishes the motor tariff schedule that all general insurers must adhere to, making pricing for standard motor products a compliance activity as much as a commercial one.

Sub-capabilities with examples: Product Design — Underwriting and Actuarial teams design a new electric vehicle (EV) motor product with battery replacement coverage; product terms drafted, legal review completed, BNM filing prepared. Product Pricing — Actuarial team builds the rate manual in MG-ALFA using 5 years of claims data; justification report prepared for BNM product filing. Product Filing (BNM) — completed actuarial report and product terms submitted to BNM Insurance Supervision Department; BNM acknowledgement received within 30 days. Product Launch — PolicyCenter product model configured; marketing materials reviewed for BNM market conduct compliance; agent training conducted before go-live. Tariff Management — ISM publishes revised motor tariff rates for July; PolicyCenter rating engine updated; all active quotes invalidated and re-rated before the effective date.

Underwriting & Risk

Underwriting & Risk is the domain where the insurer decides which risks to accept, at what price, and on what terms. In Malaysian general insurance, Motor Underwriting is the highest-volume capability — thousands of risks rated and bound each day. NCD Management is a regulated capability mandated by ISM: every motor policy must accurately reflect the policyholder's NCD entitlement from the ISM NCD database. Reinsurance Placement manages the risk transfer arrangements that protect the insurer's balance sheet from catastrophic or accumulation losses. The absence of a configurable underwriting rules engine (as found in Guidewire PolicyCenter) is the root cause of most critical UW capability gaps in the as-is state.

Sub-capabilities with examples: Risk Assessment — commercial fire risk with RM 50M sum insured assessed against flood zone exposure, sprinkler system adequacy, and occupancy class. Motor Underwriting — comprehensive motor policy rated in under 2 seconds using ISM tariff configured in PolicyCenter rating engine. NCD Management — ISM NCD API returns 38% NCD entitlement for returning policyholder; applied automatically in rating engine without human intervention. General Lines UW — liability policy for food manufacturer assessed against product recall exposure; referred to Head of UW for non-standard exclusion. Fleet Underwriting — 120-vehicle fleet account rated using experience rating formula based on 3 years of fleet loss history. Reinsurance Placement — facultative placement placed with Lloyd's syndicates for RM 200M oil & gas risk exceeding treaty capacity.

Policy Administration

Policy Administration is the operational engine of the insurer — it is the domain that processes every policy transaction from issuance to cancellation. In a high-volume motor insurer, this domain handles hundreds of thousands of policy events each year: new business issuances, mid-term endorsements (named driver additions, vehicle modifications, address changes), annual renewals, and cancellations. Document Management is a regulated sub-capability: BNM requires that policyholders receive their policy schedule and cover note within a defined timeframe, and that all policy documents are retained for 7 years. Premium Collection manages the receipt and reconciliation of premium payments across multiple channels — FPX, credit card, cash, and agent remittance.

Sub-capabilities with examples: Policy Issuance — motor comprehensive policy issued via PolicyCenter STP workflow in 45 seconds from payment confirmation; policy schedule PDF generated and emailed automatically. Policy Endorsement — policyholder submits named driver addition via self-service portal at 10pm; endorsement processed by PolicyCenter within 2 minutes; updated policy schedule delivered to email. Policy Renewal — 45,000 motor policies due for renewal in December; automated renewal notices sent 60 days prior; 78% renewed online without agent involvement. Policy Cancellation — policyholder requests cancellation; pro-rata refund calculated by PolicyCenter; refund instruction sent to Oracle Financials; refund processed within 5 business days. Document Management — all policy documents stored in AWS S3 with 7-year retention policy; accessible via customer portal at any time.

Claims Management

Claims Management is the domain most directly visible to policyholders and most closely scrutinised by BNM. The claims experience — speed of acknowledgement, fairness of assessment, efficiency of payment — is the primary driver of policyholder satisfaction and renewal intention in motor insurance. BNM's TAT obligations create a compliance dimension: every touchpoint in the claims process has a regulatory deadline, and breach of these deadlines can result in public censure, financial penalties, or enhanced supervisory oversight. Fraud Detection is a critical sub-capability that is frequently under-resourced in the as-is state — the absence of a systematic fraud scoring capability means that fraudulent claims are indistinguishable from genuine ones until they are paid.

Sub-capabilities with examples: FNOL Registration — policyholder registers accident claim via mobile app at accident scene; claim number generated within 60 seconds; adjuster assigned automatically by ClaimCenter triage rules. Claims Assessment — desk assessor reviews low-value motor claim (RM 3,500 bumper damage) using photos submitted via mobile app; assessment completed within 2 days without physical inspection. Claims Settlement — approved settlement of RM 8,500 to panel workshop; payment instruction sent from ClaimCenter to Oracle Financials; workshop paid within 14 days of repair completion. Fraud Detection — SageMaker fraud model scores incoming claim at 0.87 (HIGH RISK); claim flagged for investigation team; IFBM database confirms workshop involved in 3 prior fraud referrals. Recovery & Subrogation — third-party at-fault insurer identified; subrogation letter issued; RM 12,000 recovery received within 90 days.

Distribution & Sales

Distribution & Sales encompasses all the channels and relationships through which the insurer's products reach paying customers. In Malaysian general insurance, the distribution landscape is multi-channel and rapidly evolving: the traditional agent-dominated model is being disrupted by aggregator platforms, bancassurance integrations, and direct digital channels. Agent Management is a regulated sub-capability — BNM requires that all insurance agents hold a valid licence under the Financial Advisers Act, making agent onboarding a compliance process as well as a commercial one. Commission Management must be accurate and timely — commission disputes are among the most common complaints escalated to BNM's Financial Mediation Bureau.

Sub-capabilities with examples: Agent Management — new tied agent onboarded; BNM licence verified via API; commission schedule assigned; agent portal access provisioned; first policy submission received within 14 days. Broker Management — loss adjusting broker submits complex commercial fire claim; broker's authority level verified in Salesforce; submission routed to Senior UW automatically. Bancassurance Management — bank partner's mobile app integrates with Aggregator API; real-time motor quote returned in 280ms; policy bound within bank's digital journey without customer leaving the app. Digital Sales — customer completes motor quote-to-bind journey on insurer's website in 3 minutes 47 seconds; no agent involvement; policy issued immediately. Aggregator Management — insurer's motor quotes appear on 4 aggregator platforms; click-through conversion rate tracked per platform in Snowflake analytics dashboard.

Actuarial & Analytics

Actuarial & Analytics is the domain that provides the quantitative foundation for all business decisions — pricing, reserving, capital management, and risk strategy. In Malaysian general insurance, this domain is anchored in BNM's regulatory framework: Premium Rating outputs are filed with BNM before implementation; Loss Reserving outputs are certified by the appointed actuary and submitted to BNM in the annual regulatory return; Capital Modeling outputs underpin the RBC ratio that BNM uses to assess the insurer's financial soundness. The weakness of this domain in the as-is state — dominated by Excel workbooks and R scripts with no governed data pipeline — creates material regulatory risk.

Sub-capabilities with examples: Premium Rating — actuarial team runs MG-ALFA pricing model using 5 years of Snowflake claims data; revised motor rates filed with BNM; PolicyCenter rating engine updated with new rates after BNM approval. Loss Reserving — IBNR reserve of RM 67M calculated for motor portfolio at Q3 close; reconciled to ClaimCenter outstanding claim register; appointed actuary signs off for BNM Annual Accounts submission. Experience Analysis — loss ratio by vehicle make and model analysed in Snowflake; Proton Saga identified as highest-loss vehicle class; underwriting referral rule added to PolicyCenter. Capital Modeling — RBC ratio calculated at 142% using MG-ALFA capital model; stress test scenario applied for 1-in-100 flood event; reinsurance purchasing strategy adjusted based on output. Catastrophe Modeling — flood accumulation for Klang Valley property portfolio modelled; probable maximum loss calculated; catastrophe XL reinsurance limit increased by RM 50M for next year.

Finance & Accounting

Finance & Accounting is the domain that records, manages, and reports on all financial flows through the insurance business. In general insurance, the financial flows are more complex than in most industries: premium is written and earned over the policy period (not at inception), claims are incurred before they are reported (IBNR), and reinsurance creates a parallel set of financial entries for every underlying insurance transaction. Premium Accounting must reconcile to the PolicyCenter policy register daily. Claims Accounting must reconcile to the ClaimCenter claims ledger daily. Reinsurance Accounting must reconcile to the reinsurance bordereau monthly. All three must reconcile to each other and to the Oracle Financials general ledger before any BNM statutory return can be submitted with confidence.

Sub-capabilities with examples: Premium Accounting — 2,000 motor policies issued on a Wednesday; each triggers a POLICY_ISSUED event in PolicyCenter; MuleSoft routes event to Oracle Financials GL posting within 60 seconds; premium ledger updated in real-time. Claims Accounting — RM 8,500 panel workshop payment approved in ClaimCenter; MuleSoft Claims Settlement API sends payment instruction to Oracle Financials; payment processed within 48 hours; Oracle GL updated; reserve released in ClaimCenter. Reinsurance Accounting — monthly bordereau generated from Snowflake for quota share treaty; 45,234 motor policies included; RM 3.7M ceded premium and RM 820K ceded claims calculated; submitted to Munich Re via secure file transfer. Financial Reporting — quarterly management accounts prepared from Oracle Financials; reconciled against Snowflake regulatory dataset; submitted to BNM within 30 days of quarter end. Treasury Management — surplus premium float invested in BNM-approved government securities; investment income recorded in Oracle GL.

Compliance & Regulatory

Compliance & Regulatory is the domain that ensures the insurer operates within the boundaries set by BNM, ISM, IFBM, and other regulatory bodies. In Malaysian general insurance, this is a dense and demanding compliance landscape: BNM's FSA 2013, the Risk Management in Technology (RMiT) policy, the AML/CFT Policy, the Market Conduct Guidelines, and ISM's motor tariff regulations collectively generate dozens of periodic returns, ongoing monitoring obligations, and process compliance requirements. BNM Reporting is the most critical sub-capability — BNM's FAST portal receives quarterly financial statistics, and the quality of submissions directly influences BNM's assessment of the insurer's governance maturity. AML/CFT is an area of increasing BNM supervisory focus following several enforcement actions against financial institutions with weak screening controls.

Sub-capabilities with examples: BNM Reporting — quarterly Jadual 6 motor statistics report generated from Snowflake; data reconciled to PolicyCenter and Oracle; submitted via BNM FAST portal within deadline; BNM acknowledgement received. ISM Reporting — monthly motor data file containing 45,000 policy records generated from Snowflake; submitted to ISM via SFTP on the 1st of each month; ISM NCD database updated with new policy information. Product Compliance — new EV motor product terms reviewed against BNM market conduct guidelines before filing; mandatory disclosure language updated; BNM approval received before product launch. AML/CFT — new commercial property policyholder screened automatically against OFAC, UN, and BNM sanctions lists; clear result recorded with timestamp in Snowflake AML audit log; policy bound immediately. Market Conduct — BNM mystery shopping exercise reveals complaint TAT breach; remediation plan submitted to BNM within 30 days; process automation implemented in Salesforce to prevent recurrence.

Technology & Operations

Technology & Operations is the domain that delivers and manages the technology platform that every other capability depends on. In a digital insurer, this domain is not a support function — it is a core business capability that directly determines the speed, reliability, and security of insurance service delivery. Platform Engineering owns the Guidewire Cloud platform, its quarterly update cycle, and the configuration release management process that ensures new product rules and workflow changes are deployed safely. API Management is the governance capability that enforces the Single Integration Backbone principle — without it, point-to-point integrations proliferate unchecked, creating the very integration sprawl that the modernization program is designed to eliminate. Security Management is a regulated capability under BNM's RMiT policy, which mandates specific controls for access management, vulnerability management, and incident response.

Sub-capabilities with examples: Platform Engineering — Guidewire quarterly cloud update deployed to staging environment; regression test suite run against all motor and general lines workflows; zero defects in TAT-critical paths; deployed to production in 4-hour maintenance window. IT Operations — MuleSoft API runtime CPU utilisation spikes to 85% during December motor renewal peak; AWS EKS horizontal pod autoscaler adds 3 additional runtime pods within 90 seconds; API latency returns to normal; no consumer impact. Data Management — Snowflake data quality check detects 12 policies in PolicyCenter not reflected in Snowflake data domain; data reconciliation job reruns; discrepancy resolved; root cause identified as missed event in MuleSoft event stream. API Management — new bancassurance partner requests access to Aggregator API; MuleSoft developer portal used for API registration; OAuth 2.0 client credentials issued; rate limiting configured; ARB integration design review completed before go-live. Security Management — quarterly vulnerability scan of AWS infrastructure identifies 2 medium-severity findings; remediation completed within BNM RMiT-required 30-day window; finding evidence uploaded to BNM examination readiness tracker.

ENQUIRY — Policy Acquisition Step 1

What happens: Customer contacts the insurer via agent, direct channel, aggregator, or bancassurance partner to express interest in cover. Channel is recorded. Risk details are captured.

Who does it: Customer, Agent, or Aggregator Platform. System: Salesforce FSC (CRM lead capture), Agent Portal (Experience API), Aggregator API. Data created: Lead record, channel identifier, customer contact details, risk details (vehicle reg, IC number). What can go wrong: No lead is captured — prospect abandons. If aggregator API is down, the insurer is invisible on price comparison platforms during peak renewal season. Call centre queue at full capacity cannot handle inbound volume — customers routed to voicemail, TAT clock still starts from first contact.

QUOTE — Policy Acquisition Step 2

What happens: Risk is rated using vehicle data, policyholder profile, NCD entitlement (from ISM), and the ISM motor tariff applied in PolicyCenter's rating engine. A premium is calculated and presented to the customer.

Who does it: PolicyCenter Rating Engine (automated), with referral to underwriter for non-standard risks. System: Guidewire PolicyCenter, ISM NCD API (via MuleSoft NCD Check Process API), MG-ALFA rating tables. Data created: Quote record with premium breakdown, rating factors used, NCD percentage applied, quote expiry timestamp. What can go wrong: If NCD API is unavailable, NCD cannot be verified — insurer either quotes without NCD (overcharging the customer, triggering BNM complaints) or cannot quote at all. If rating engine is misconfigured after a product update, premium is wrong — underpricing creates adverse selection risk; overpricing loses business to competitors on aggregator platforms.

BIND — Policy Acquisition Step 3

What happens: Customer accepts the quoted premium, pays via FPX, credit card, or cash, and the policy is legally bound — insurer is now at risk. Cover is confirmed immediately on successful payment.

Who does it: Customer (self-service) or Agent (on behalf of customer); Payment Gateway processes payment. System: PolicyCenter (bind action), Payment Gateway (FPX/card processing), MuleSoft (Quote & Bind Process API). Data created: Bound policy record, payment confirmation, policy number assigned, cover start date confirmed. What can go wrong: If payment gateway is unavailable, no premium is collected and no policy is bound — revenue stops. If PolicyCenter fails to record the bind, the customer has paid but has no cover — a BNM market conduct breach. If the payment succeeds but the bind event fails to reach Oracle Financials, premium is not posted — financial accounts understated.

ISSUE — Policy Acquisition Step 4

What happens: PolicyCenter generates the policy schedule PDF, cover note, and any endorsement documents; documents are delivered to the customer via email or portal. The policy is now in force and the customer has evidence of cover.

Who does it: PolicyCenter (automated document generation), Document Management system. System: Guidewire PolicyCenter (doc generation), AWS S3 (document storage), Email/Portal delivery service. Data created: Policy schedule PDF, cover note, policy number, digital document delivery confirmation. What can go wrong: If document generation fails, the customer has no evidence of cover — cannot register the vehicle with JPJ without a cover note. BNM requires evidence of cover to be delivered promptly — failure is a market conduct breach and a customer complaint risk that triggers the BNM TAT clock for complaint resolution.

FNOL — Claims Settlement Step 1

What happens: Claimant notifies the insurer of a loss — accident, theft, fire. Claim handler registers the claim, verifies policy coverage, and assigns the claim to an adjuster or desk assessor.

Who does it: Claims handler (call centre or self-service portal); ClaimCenter automated triage rules. System: Guidewire ClaimCenter, MuleSoft FNOL Process API, Salesforce (customer lookup), PolicyCenter (coverage verification). Data created: Claim number, FNOL date/time, loss description, vehicle details, policy coverage confirmation, initial reserve estimate. What can go wrong: If ClaimCenter is unavailable, FNOL cannot be registered — BNM TAT clock starts from the customer's notification date regardless of system availability. Delay in FNOL registration means TAT breach risk from day one of the claim. If coverage verification fails, the claim may proceed without confirming the policy is in force — paying a claim on a lapsed policy.

ASSESSMENT — Claims Settlement Step 2

What happens: Loss adjuster or desk assessor inspects damage, reviews repair estimates from panel workshop, and submits an assessment report with recommended quantum.

Who does it: Panel loss adjuster (field), desk assessor (in-house for low-value claims). System: ClaimCenter (assessment workflow), mobile adjuster app (photo/report upload), parts pricing database. Data created: Assessment report, repair estimate, photos, liability determination, recommended reserve adjustment. What can go wrong: If the adjuster mobile app fails, reports must be submitted via email — manual data entry into ClaimCenter introduces errors and delays. If the parts pricing database is unavailable, repair quantum cannot be validated — overpayment risk. If the adjuster's recommended reserve is not uploaded promptly, the actuarial reserve is understated — BNM RBC capital calculation inaccurate.

DECISION — Claims Settlement Step 3

What happens: Claims manager reviews assessment report and fraud score (from SageMaker), confirms coverage, approves or rejects the claim, and sets the final settlement quantum.

Who does it: Claims manager (authorised by delegated authority matrix); fraud score provided by SageMaker API. System: ClaimCenter (decision workflow), SageMaker Fraud Check API (via MuleSoft), IFBM fraud database lookup. Data created: Claim decision (approved/rejected/disputed), final quantum, fraud score, decision rationale, reserve finalisation. What can go wrong: If the fraud scoring API is unavailable, the decision is made without fraud intelligence — fraudulent claims are paid. If delegated authority controls fail, claims above the manager's limit are approved without proper oversight — financial control breach and internal audit finding. If the decision is delayed beyond BNM TAT threshold, an automatic escalation should trigger — if this alert fails, TAT breach occurs silently.

SETTLEMENT — Claims Settlement Step 4

What happens: Approved payment is disbursed to the panel workshop (for repairs) or directly to the policyholder (for total loss or cash settlements); payment instruction sent from ClaimCenter to Oracle Financials.

Who does it: Claims administrator (payment instruction); Oracle Financials (payment processing); bank (funds transfer). System: ClaimCenter (settlement action), MuleSoft Claims Settlement API, Oracle Financials Cloud (payment processing), banking system. Data created: Payment reference, amount, payee details, payment date, claims ledger entry, reinsurance recovery trigger (if applicable). What can go wrong: If the Oracle Financials integration fails, payments cannot be processed — workshop holds the repaired vehicle, policyholder is without transport, BNM TAT is breached. If payment is posted to the wrong payee, financial loss and reputational damage result. If the reinsurance recovery trigger fails to fire, the cession is missed — insurer retains loss that should have been ceded to the reinsurer.

CLOSE — Claims Settlement Step 5

What happens: Claim file is closed after payment confirmation; subrogation or recovery action is initiated if applicable; reinsurance recovery bordereau is updated; actuarial reserve is released.

Who does it: Claims administrator (file closure); recovery unit (subrogation); reinsurance team (bordereau update). System: ClaimCenter (closure workflow), Oracle Financials (reserve release), reinsurance bordereau system. Data created: Claim closure date, final paid amount, recovery amount (if applicable), reserve release, closed claim data pushed to Snowflake for actuarial analysis. What can go wrong: If file closure is not recorded promptly, reserves are not released — overstated liabilities affect the RBC ratio and may trigger unnecessary capital calls. If subrogation is not initiated, recoverable amounts are lost permanently. If closed claim data does not reach Snowflake, the IBNR model in MG-ALFA is trained on incomplete data — reserve adequacy calculation is inaccurate.

REMINDER — Policy Renewal Step 1

What happens: Automated renewal reminder sent to policyholder 60 days before expiry (second reminder at 30 days), via email, SMS, or WhatsApp, with a pre-filled renewal quote.

Who does it: Automated (Salesforce Marketing Cloud or equivalent); human follow-up for high-value or at-risk accounts. System: Salesforce FSC (renewal campaign), MuleSoft Re-Quote Process API, PolicyCenter (renewal quote generation). Data created: Renewal notice record, communication delivery confirmation, pre-filled quote amount, campaign tracking ID. What can go wrong: If reminders fail to send, customers do not know their policy is expiring — lapse rate increases significantly. In motor insurance, an unaware customer may drive uninsured after expiry — a JPJ compliance risk for the customer and a reputation risk for the insurer. If the renewal quote included in the reminder is incorrect (wrong NCD, wrong premium), the customer receives misleading information — BNM market conduct breach.

RE-QUOTE — Policy Renewal Step 2

What happens: PolicyCenter calculates the renewal premium applying updated NCD entitlement (from ISM), any claims-related NCD reduction from the previous year, updated vehicle sum insured, and current tariff rates.

Who does it: PolicyCenter rating engine (automated); ISM NCD API (NCD verification). System: Guidewire PolicyCenter, MuleSoft NCD Check Process API, ISM NCD system, MG-ALFA (if rate revision applicable). Data created: Renewal quote, NCD percentage applied, NCD source (ISM verification), premium breakdown, quote validity period. What can go wrong: If ISM NCD API fails, NCD cannot be verified — the insurer must either delay quoting or apply NCD based on internal records (which may be stale). Incorrect NCD application results in premium errors — overcharging triggers BNM complaints, undercharging results in premium shortfall. If a rate revision has been applied without proper notification, the renewed premium may surprise the customer — creating a cancellation and complaint risk.

RENEWAL BIND — Policy Renewal Step 3

What happens: Customer accepts renewal premium, pays online or through agent, and PolicyCenter renews the policy — generating new policy period, updating cover dates, and triggering premium accounting in Oracle.

Who does it: Customer (self-service) or Agent; PolicyCenter (policy renewal action); Oracle Financials (premium accounting). System: PolicyCenter (renewal bind), Payment Gateway, MuleSoft Quote & Bind API, Oracle Financials (premium posting). Data created: Renewed policy record, new policy period dates, payment confirmation, premium accounting entry, renewed policy schedule PDF. What can go wrong: If payment processing fails, premium is not collected but the policy may still be flagged as renewed in some systems — creating a coverage-without-payment gap. If Oracle Financials fails to receive the premium posting, the finance accounts are understated — audit and BNM statutory return accuracy risk. During December peak, payment gateway must handle 3–4x normal volume — capacity planning failure causes timeout errors and customer frustration.

RETAIN / LAPSE — Policy Renewal Step 4

What happens: If renewed, the policy becomes active for a new period and Salesforce records the retention. If the customer does not renew, the policy lapses and Salesforce triggers a lapse recovery campaign.

Who does it: Automated (Salesforce campaign); retention agents for high-value lapsed policyholders. System: Salesforce FSC (retention campaign), SageMaker (lapse propensity model for targeted outreach), PolicyCenter (lapse recording). Data created: Retention or lapse outcome, lapse reason code (if captured), recovery campaign trigger, lifetime value update in CRM. What can go wrong: If lapse recording fails, expired policies remain "active" in the system — the insurer may pay claims on lapsed policies or send renewal notices for policies that have already lapsed. If the retention campaign fails, lapsed customers are not contacted — revenue recovery opportunity is permanently lost. If the SageMaker propensity model is stale (trained on outdated data), high-risk customers are not correctly prioritised — retention resource is wasted on low-risk customers while high-value accounts lapse.

Business Layer — As-Is

The business layer in the as-is state operates largely independently of any digital capability. Underwriting decisions are made manually by staff using a combination of legacy PAS screens and physical underwriting guidelines printed from PDF manuals. Claims operations depend on a combination of the legacy CMS and physical claim files that are physically moved between assessors and managers for signature. Sales and distribution is driven through a paper-based agent submission process, with agents completing physical proposal forms that are couriered or faxed to the underwriting department for data entry.

Specific systems: No CRM system — customer records maintained in legacy PAS customer module with no integration to sales management. Agent management done via Excel commission tracking spreadsheets updated monthly. Compliance monitoring done manually by the compliance team reading system-generated reports and manually checking TAT records. Limitations: Experienced staff who know how to navigate the legacy system's limitations are the primary control mechanism — their departure creates immediate operational risk. No workflow automation means that process performance is entirely dependent on individual staff discipline. Regulatory risks: BNM TAT monitoring relies on manual tracking — TAT breaches are discovered after the fact, not prevented in real time. AML/CFT screening is manually performed against printed sanctions lists — not automated, not auditable to BNM's satisfaction.

Application Layer — As-Is

The application layer is anchored by the Legacy Core PAS — a policy administration and claims management monolith implemented in the early 2000s and patched incrementally ever since. This system was built on a proprietary database schema with no API layer, meaning that any system that needs data from it must either query its database directly or receive a nightly batch extract. The codebase is typically COBOL, Delphi, or early Java — with no surviving unit tests, limited documentation, and code so tightly coupled that a change to the motor rating logic can break the personal accident module.

Specific systems: Legacy Core PAS — handles motor and general policy issuance, claims management, and basic agent commission calculation. Has no REST API; integrated via direct database queries or nightly flat file extracts. Standalone Agent Portal — custom-built web application communicating with PAS via nightly batch file; an agent submitting a policy at 4pm will not see it confirmed until the following morning. Excel/R Spreadsheets — entire actuarial pricing models, commission calculation sheets, and regulatory return templates live as Excel files on individual laptops with no version control or access governance. Legacy ERP — customised generic ERP (JD Edwards or SAP R/3) handling finance but not integrated in real-time with the PAS — premium postings done via nightly batch file, meaning the finance team is always one day behind the underwriting position. Limitations: The Legacy PAS is the single most critical source of technical risk — it has no API layer, no configurable rules engine, no modern document generation capability, and no workflow automation. Any modernization program must treat it as the primary decommission target. Regulatory risks: The legacy PAS cannot generate BNM TAT compliance reports in real time — TAT monitoring requires manual extraction. ISM motor data submissions require a monthly manual export process from the PAS database — prone to extraction errors and formatting failures.

Integration Layer — As-Is

The integration layer in the as-is state is not an integration layer at all — it is a collection of ad hoc connections that grew organically over decades as each new integration need arose. Point-to-point file transfers between the legacy PAS and the ERP, between the agent portal and the PAS, and between the PAS and ISM are the primary integration mechanism. Nightly batch jobs run overnight to synchronise data between systems — meaning that the business operates on data that is always at least one day old. Direct database calls from the agent portal and reporting tools into the PAS database bypass any application logic, creating data integrity risks.

Specific connections: Legacy PAS → Legacy ERP: nightly flat file of premium transactions posted to ERP GL; any failure in this batch means the finance team cannot close the daily books. Legacy PAS → ISM: monthly CSV file of motor policy data submitted via SFTP; if the file fails validation, the entire month's NCD database update is rejected by ISM. Agent Portal → Legacy PAS: nightly batch synchronisation; agents cannot see today's policy confirmations until tomorrow morning. Limitations: No monitoring — if a batch job fails overnight, the failure is typically discovered by a business user the following morning when they notice data is missing. No retry mechanism — a failed batch must be manually re-run by IT operations, introducing further delay. No API governance — any developer can add a new direct database call to the PAS database without architectural review. Regulatory risks: The absence of an API layer means that there is no single point at which security controls (authentication, rate limiting, audit logging) can be enforced across all system integrations. Direct database access from external-facing systems is a BNM RMiT compliance risk.

Data Layer — As-Is

The data layer in the as-is state does not exist as a distinct architectural component — data sits in application databases and spreadsheets, with no central platform, no data governance framework, and no consistent data model across systems. The PAS database schema is the closest thing to a data platform, but it is a transactional database optimised for policy processing, not for analytics or regulatory reporting. The finance team, actuarial team, and compliance team each maintain their own data extracts from the PAS — meaning that three versions of the same data exist simultaneously, each potentially differing from the others.

Specific issues: Customer data exists in at least three places: the legacy PAS (policyholder record), the agent portal (agent-maintained customer data), and multiple Excel spreadsheets (campaign management, complaint tracking). There is no master customer ID — the same customer may have different identifiers in each system. Regulatory reporting data is assembled manually each quarter by the compliance team — a process that takes 5–7 business days and involves reconciling exports from the PAS, the ERP, and multiple spreadsheets. Actuarial pricing models in Excel have no version control — the "current" pricing model is whatever is on the lead actuary's laptop, with no audit trail of changes. Limitations: No governed data — any data extracted from the PAS is immediately subject to manual transformation and therefore to transcription error. No lineage — it is impossible to trace a number in a BNM return back to its source record in the PAS without manual investigation. Regulatory risks: BNM requires that regulatory returns are accurate and auditable. The manual data assembly process creates a risk of submission error — BNM has taken enforcement action against Malaysian insurers for submission inaccuracies. The absence of PII data governance means customer data is stored in unencrypted spreadsheets on laptops — a data protection breach risk.

Infrastructure Layer — As-Is

The infrastructure layer is entirely on-premise — all servers, storage, and networking are located in an owned or co-located data centre. This was the appropriate architecture when the systems were built in the early 2000s, but it creates significant constraints for a modernization program: the hardware is approaching end-of-life, replacement hardware requires long procurement cycles, and the on-premise model cannot provide the elastic scaling that a digital insurance operation requires during peak periods.

Specific systems: Primary data centre — physical servers running legacy PAS, legacy ERP, and agent portal. Typically 5–10 years old. DR data centre — a secondary site with manual failover capability; RTO of 24–48 hours, which is not compatible with BNM's expectation that critical systems should recover within a defined timeframe. Network — perimeter firewall with flat internal network; no zero-trust model; all internal systems can reach each other without restriction. Limitations: Motor renewal peaks (December) require 3–4x normal compute capacity — the on-premise infrastructure is sized for average load, not peak load. During peak periods, the legacy PAS experiences performance degradation that manifests as slow response times for agents and call centre staff — causing TAT pressure as staff cannot process transactions at the required rate. Manual DR process requires IT operations to physically travel to the DR site to initiate failover — adding hours to the recovery time. Regulatory risks: BNM's RMiT policy requires that insurers maintain a tested business continuity plan with a defined and achievable RTO. The current 24–48 hour RTO for the legacy PAS is a compliance risk that BNM has flagged in examination findings at peer institutions. Data centre physical security must meet BNM's standards — ageing facilities may not comply with current BNM expectations for access control, fire suppression, and environmental monitoring.

Underwriting & Risk — Gap Theme

The Underwriting & Risk domain gaps are fundamentally caused by the absence of a configurable rules engine — the legacy PAS has underwriting logic hardcoded into its application layer, making it impossible to change rating rules, add new NCD brackets, or introduce new motor product variants without a code deployment. Business rules that Underwriting wants to change in response to market conditions take 3–6 months to implement, by which time the competitive window has closed. If these gaps are not fixed, the insurer cannot respond to BNM's progressive motor tariff liberalisation — which will require freely rated motor products supported by actuarially justified pricing models that the current system cannot produce.

Claims Management — Gap Theme

The Claims Management domain gaps are the highest regulatory-risk gaps in the entire gap analysis — BNM's claims TAT obligations mean that a broken claims process is not just an operational problem but a direct regulatory exposure. The root cause of all three Critical gaps is the absence of Guidewire ClaimCenter: the legacy CMS has no workflow automation, no STP rules, no fraud detection capability, and no TAT monitoring dashboard. Every claim is manually managed from FNOL to settlement, which means TAT compliance depends entirely on individual claims handlers remembering to act within the required timeframe. If these gaps persist, the insurer faces escalating BNM enforcement risk as BNM's supervisory intensity on claims TAT has increased materially since 2022.

Technology & Operations — Gap Theme

The Technology & Operations domain gaps represent the infrastructure enablers without which no other gap can be addressed. The absence of an API layer is the most foundational gap: without MuleSoft, there is no mechanism to connect Guidewire to the legacy system during coexistence, no way to expose insurance capabilities to digital channels, and no governance over system-to-system integration. The data management gap is the second-most-critical: without Snowflake as a central data platform, BNM reporting will remain manual, actuarial models will remain spreadsheet-based, and SageMaker fraud models will have no governed training data to learn from. These two gaps must be closed in Phase 1 — they are the prerequisite for every other Phase 2 and Phase 3 delivery.

Business Layer — To-Be

The Business Layer is the top-most layer of the landscape model and represents the insurance functions that the technology exists to serve. It is listed in the landscape model not as a technology component but as an architectural anchor — a reminder that every system in the layers below must be traceable to a business function it serves. In the target landscape, the business layer functions are the same as the as-is: Underwriting, Claims, Sales & Distribution, Actuarial, and Finance. What changes is the quality, speed, and automation of the technology that enables them.

What changes vs as-is: Underwriting — moves from manual rule application to automated PolicyCenter rules engine with configurable UW authority matrix. Claims — moves from manual adjuster coordination to automated ClaimCenter workflow with real-time BNM TAT monitoring. Sales & Distribution — moves from agent-led paper submissions to omnichannel digital distribution via Salesforce FSC and MuleSoft Experience APIs. Actuarial — moves from Excel-based manual models to governed Snowflake data pipelines feeding MG-ALFA with reconciled source data. Finance — moves from day-late batch reconciliation to real-time event-driven premium and claims accounting in Oracle Financials.

Application Layer — To-Be

The Application Layer contains the purpose-built software systems that deliver insurance business capabilities. Each system represents a deliberate buy-versus-build decision: rather than building a custom policy administration system, the insurer buys Guidewire PolicyCenter, which comes pre-configured with decades of insurance business logic. This shifts the value-add work from building core insurance logic to configuring and extending a proven platform — a significantly lower-risk approach in a regulated environment. The Application Layer is also the layer where the Strangler Fig migration pattern operates: during the transition, both the legacy PAS and Guidewire PolicyCenter coexist in this layer, with MuleSoft routing traffic between them based on migration phase.

Systems and their roles: Guidewire PolicyCenter Cloud — core policy administration for motor and general lines; configurable rating engine; STP issuance; NCD application; document generation. Guidewire ClaimCenter Cloud — claims lifecycle management from FNOL to closure; automated triage; BNM TAT monitoring; fraud scoring integration. Salesforce Financial Services Cloud — CRM for customer, agent, and broker management; renewal campaigns; complaint tracking; omnichannel interaction history. Milliman MG-ALFA — actuarial pricing and reserving models; rate tables output to PolicyCenter; IBNR calculations. Oracle Financials Cloud — GL, accounts payable, premium accounting, claims payment processing, financial reporting.

Integration Layer — To-Be

The Integration Layer is the most architecturally distinctive feature of the target landscape compared to the as-is state — it is the layer that does not exist today and whose absence is the root cause of most of the critical gaps identified in the gap analysis. The Integration Layer's purpose is to decouple all application-to-application communication, enforce API standards, provide a single point of governance and monitoring, and enable the coexistence architecture during the strangler fig migration. The Integration Layer is owned by the Technology & Operations function and governed by the ARB through API design standards, versioning policy, and consumer onboarding controls.

MuleSoft Anypoint Platform is the single approved integration platform — it implements the 3-layer API-led architecture (Experience, Process, System) and hosts all APIs on a shared runtime infrastructure. In the insurance context, MuleSoft enables: the aggregator to receive a motor quote in under 500ms; the bancassurance partner to bind a policy in real-time; the ISM NCD check to be performed automatically during every motor renewal quote; and the fraud score to be injected into the claims assessment workflow without any manual step. Its API Gateway capability provides rate limiting, authentication enforcement, and consumer-level analytics.

Data Layer — To-Be

The Data Layer separates the concern of data storage and analytics from the concern of transaction processing. This separation is critical for performance (analytics queries against Snowflake do not compete with transaction processing in PolicyCenter), for governance (all data in Snowflake is subject to the data governance framework), and for regulatory compliance (all BNM returns are produced from Snowflake, ensuring they are reconciled against source systems before submission).

Snowflake (Data Warehouse) — the central data platform and single source of truth for all analytics, regulatory reporting, and AI model training. Holds complete policy, claims, customer, and financial data domains. Produces all BNM regulatory returns via governed SQL transformations. Connects to Application Layer via real-time event streams and daily batch loads. AWS SageMaker (AI/ML) — machine learning platform that trains, hosts, and monitors AI models. Hosts the fraud scoring model (called in real-time during claims assessment), the NCD propensity model (for retention campaigns), and the pricing segmentation model (feeds MG-ALFA pricing analysis). Model registry tracks all model versions, training data lineage, and deployment history — satisfying ARB model governance requirements.

Infrastructure Layer — To-Be

The Infrastructure Layer provides the cloud computing foundation that makes the entire target landscape possible. Unlike the as-is on-premise infrastructure, the AWS infrastructure provides elastic scaling (handling motor renewal peak loads 3–4x the monthly average without pre-provisioning hardware), managed services, and enterprise-grade reliability (multi-availability-zone deployments with automated failover, RTO measured in minutes rather than hours). The Infrastructure Layer is governed by cloud infrastructure standards published by the ARB. BNM's data localisation requirements are satisfied by constraining all AWS workloads to the AWS Asia Pacific (Kuala Lumpur) region.

AWS EKS — hosts all containerised application workloads including MuleSoft Anypoint runtime, enabling zero-downtime deployments and automatic scaling during motor renewal peaks. AWS EventBridge — the event bus that routes asynchronous events between systems; decouples producers from consumers; enables the event-driven integration pattern (policy-issued events to Oracle, claim-settled events to reinsurance systems). AWS S3 — document storage for all policy schedules, cover notes, and claim documents; 7-year retention policy configured; accessible via customer portal. AWS CloudWatch — unified monitoring for all API, application, and infrastructure metrics; automated alerts for SLA breaches; integration with incident management.

Guidewire PolicyCenter Cloud

PolicyCenter is the core policy administration system — it owns the entire policy lifecycle from submission and rating through to issuance, endorsement, renewal, and cancellation. In the insurance context, PolicyCenter enables automated motor underwriting using the ISM tariff schedule configured in its rating engine, NCD application after real-time verification from the ISM NCD API, STP policy issuance within seconds of premium payment, and configurable underwriting authority rules that enforce delegation limits without manual sign-off. PolicyCenter connects to the MuleSoft Integration Layer via the PolicyCenter System API — all consumers (Agent Portal, Aggregator API, Bancassurance API) access PolicyCenter through this API rather than directly, ensuring that changes to PolicyCenter's internal data model do not break consumer integrations. It also feeds the Data Layer via real-time event streaming to Snowflake. Guidewire releases quarterly cloud updates — the System API abstraction layer means these updates do not require changes to any Process or Experience APIs.

Guidewire ClaimCenter Cloud

ClaimCenter is the core claims management system — it owns the claims lifecycle from FNOL registration through assessment, decision, settlement, and file closure. ClaimCenter enables automated adjuster assignment using configurable triage rules (loss type, claim value, location), STP settlement for low-value claims that meet straight-through criteria, real-time BNM TAT monitoring with automated escalation alerts when claims approach TAT thresholds, and integration with the SageMaker fraud scoring model via the MuleSoft Fraud Check Process API. ClaimCenter connects to Oracle Financials via the MuleSoft Claims Settlement API — payment instructions are sent from ClaimCenter to Oracle, which processes the actual bank transfer, and the payment confirmation is returned to ClaimCenter to update the claim record. ClaimCenter data flows to Snowflake in real-time for actuarial reserving analysis and BNM regulatory reporting. TAT monitoring built directly into ClaimCenter workflow — TAT breaches trigger automated escalation alerts, not discovered through manual monitoring.

Salesforce Financial Services Cloud

Salesforce FSC is the CRM platform that owns the customer record, distribution channel management, and renewal and retention workflow. Salesforce enables agent and broker management (licensing status, production tracking, commission statements), omnichannel customer interaction history (every call, email, claim, and complaint consolidated in one customer view), automated renewal campaigns triggered 60 and 30 days before policy expiry, and lapse recovery campaigns targeting customers who did not renew within 14 days of expiry. Salesforce connects to the MuleSoft Integration Layer via the Customer Portal Experience API (for self-service customers) and the Agent Portal Experience API (for agents). It receives policy and claims data from Snowflake to display a unified customer view, and it pushes campaign response data to Snowflake for SageMaker propensity models to train on. Salesforce must be hosted in AWS KL region (private tenant) to satisfy BNM data localisation requirements for customer PII.

Milliman MG-ALFA

MG-ALFA is the actuarial modelling platform used for premium rating, loss reserving, and capital modelling. MG-ALFA maintains the actuarial pricing models that determine the base rates loaded into PolicyCenter's rating engine — without MG-ALFA, the insurer has no actuarially justified basis for its premium rates, which is a BNM product filing requirement. MG-ALFA receives loss data from Snowflake (historical claims by vehicle class, sum insured band, driver age, and region) to update its pricing models quarterly, and its output rate tables are exported to PolicyCenter's rating configuration. MG-ALFA is primarily a batch system — it does not participate in the real-time API architecture — but its output data products are critical inputs to PolicyCenter and Snowflake. The EA must ensure that the data pipeline between Snowflake and MG-ALFA is governed by a formal data contract and that rate table updates to PolicyCenter follow the ARB-approved change management process with appointed actuary sign-off before activation.

Oracle Financials Cloud

Oracle Financials Cloud is the General Ledger, Accounts Payable, and financial reporting system. Oracle receives premium accounting entries from PolicyCenter via a MuleSoft event-driven integration (policy issued triggers a premium posting), claims payment instructions from ClaimCenter (approved settlement triggers a payment disbursement), and reinsurance cession entries from the reinsurance bordereau process. Oracle is the system of record for all financial data — the premium ledger, claims ledger, and reinsurance account — and produces the financial statements and BNM statutory returns in conjunction with Snowflake. The Oracle-to-Snowflake integration runs as a daily batch (premium and claims accounting entries posted to Snowflake each night for regulatory reporting), while the real-time events (policy issuance and claim settlement) trigger immediate postings via MuleSoft. Oracle connects to adjacent layers via the MuleSoft Oracle System API, which abstracts Oracle's internal data model from the Process API layer.

MuleSoft Anypoint Platform

MuleSoft Anypoint is the single approved integration platform — it implements the 3-layer API-led architecture (Experience, Process, System) and hosts all APIs on a shared runtime infrastructure running on AWS EKS. In the insurance context, MuleSoft enables the aggregator to receive a motor quote in under 500ms, the bancassurance partner to bind a policy in real-time from within the bank's mobile app, the ISM NCD check to be performed automatically during every motor renewal quote, and the fraud score to be injected into the claims assessment workflow without any manual step. MuleSoft connects above to all consumer channels (portals, aggregators, bancassurance) and below to all backend systems (PolicyCenter, ClaimCenter, Salesforce, Oracle, legacy PAS). Its API Gateway capability provides rate limiting, authentication enforcement, and consumer-level analytics. During the strangler fig migration, MuleSoft System APIs are the critical coexistence enabler — routing traffic between legacy and modern systems by changing a single configuration without touching consumer APIs.

Snowflake

Snowflake is the central data platform — the single source of truth for all analytics, regulatory reporting, and AI model training. Snowflake holds the complete policy data domain (every policy, endorsement, renewal, and cancellation from PolicyCenter), the complete claims data domain (every claim, reserve movement, payment, and recovery from ClaimCenter), the customer data domain (every customer record, interaction, and complaint from Salesforce), and the financial data domain (every premium and claims accounting entry from Oracle). Snowflake produces all BNM regulatory returns — the monthly ISM motor statistics submission, the quarterly BNM financial statistics return, and the annual RBC capital adequacy data — by running governed SQL transformations against its data domains. All BNM submissions flow through Snowflake to ensure reconciliation against source systems. PII data is encrypted at rest. 7-year retention policy configured. Non-production environments use masked data. Snowflake connects to the Application Layer via real-time event streams from Guidewire and Salesforce (via MuleSoft) and daily batch loads from Oracle Financials.

AWS SageMaker

AWS SageMaker is the machine learning platform that trains, hosts, and monitors AI models for the insurance business. SageMaker hosts three primary models: the fraud scoring model (trained on historical claims with confirmed fraud labels, called in real-time during claims assessment via the MuleSoft Fraud Check Process API), the NCD propensity model (predicts which policyholders are likely to lapse at renewal, called by Salesforce to prioritise retention campaigns), and the pricing segmentation model (identifies risk segments that the actuarial tariff does not differentiate — feeds MG-ALFA pricing analysis). SageMaker receives training data from Snowflake (governed, labelled datasets with clear data lineage), and its trained model endpoints are called by MuleSoft Process APIs in real-time during operational workflows. The model registry in SageMaker tracks all model versions, training data lineage, and deployment history — satisfying the ARB model governance requirement that any AI model influencing a customer-facing or regulatory outcome must be explainable and auditable. Fraud model decisions are advisory (not automated denials) per ARB decision ADR-013.

Experience API Layer

Experience APIs are the outermost layer — tailored to the specific needs of each consumer channel. Each Experience API presents data in the format, vocabulary, and latency profile that its consumer expects, composing capabilities from the Process API layer to deliver a complete experience. Experience APIs are the only APIs that external parties (aggregators, bancassurance partners, regulators) interact with — they never call Process or System APIs directly.

Customer Portal API: Called by the customer self-service web portal and mobile application. Authenticated policyholders view policies, make endorsements, register claims, or pay renewals. Composes the Quote & Bind Process API (for renewals), the Policy Endorsement Process API (for mid-term changes), and the FNOL Process API (for claim registration). If this API fails, self-service customers cannot access any digital functionality — all traffic must be rerouted to the call centre, causing queue backlogs and BNM TAT risk.

Agent Portal API: Called by the agent portal web application used by tied agents and brokers to submit new business, check policy status, and retrieve commission statements. Composes the Quote & Bind Process API, the Commission Process API, and the Policy Endorsement Process API. If this API fails, agents revert to paper proposal forms — processing delay of 1–3 business days and high data entry error rate.

Aggregator API: Called by external price comparison platforms (PolicyStreet, iMoney, RinggitPlus). The aggregator sends a motor quote request and expects a premium response within 500ms — aggregator platforms reject responses slower than this threshold. If this API fails or exceeds latency thresholds, the insurer's quotes are removed from the aggregator platform — invisible to thousands of price-shopping motor customers during the renewal peak.

Bancassurance API: Called by bancassurance partner banks. The bank sends customer data, product selection, and payment confirmation, and expects a bound policy and policy document URL within 1–2 seconds. Must satisfy the bank's API contract specifications. If this API fails, the bancassurance SLA (typically 99.9% availability) is breached, triggering financial penalties.

Regulatory API: Called by internal regulatory reporting processes. Exposes regulatory datasets from Snowflake in the format required by BNM and ISM submission templates. If this API fails, regulatory return preparation reverts to manual SQL queries and manual data assembly — reintroducing the error-prone manual process the Regulatory API was built to eliminate.

Process API Layer

Process APIs orchestrate business processes by composing multiple System APIs. They encode business logic — the sequence of system calls, data transformations, and conditional rules that constitute an insurance business process. Process APIs are reusable across Experience APIs: the Quote & Bind Process API is called by both the Customer Portal API and the Aggregator API, ensuring that the rating logic and NCD verification process is identical regardless of channel.

Quote & Bind Process API: Orchestrates the complete motor quoting and binding process. Request payload: vehicle registration, IC number, cover type, sum insured, cover start date. Calls ISM NCD Check System API (retrieve NCD entitlement), PolicyCenter System API (rate the risk, generate quote, bind policy), and Oracle System API (trigger premium accounting). If this API fails, the entire acquisition value stream stops — no quotes, no policies, no premium collected.

NCD Check Process API: Orchestrates the NCD verification process with ISM. Request payload: IC number, vehicle registration, previous policy number. Calls ISM API Adapter System API. Response: NCD percentage, NCD effective date, any NCD reduction from previous year's claims, ISM verification reference number. Latency must be under 400ms. If this API fails, NCD cannot be verified — either overcharging the customer (BNM complaint risk) or applying stale internal records (ISM audit exposure).

FNOL Process API: Orchestrates the First Notification of Loss registration. Validates the policy (calling PolicyCenter System API), creates the claim in ClaimCenter (calling ClaimCenter System API), assigns an adjuster, and triggers the initial fraud score (calling Fraud Check Process API). If this API fails, FNOL cannot be registered digitally — BNM TAT compliance is immediately at risk.

Fraud Check Process API: Orchestrates the fraud scoring process. Calls the SageMaker System API (ML fraud score) and the IFBM API Adapter System API (IFBM fraud database check). Response: fraud score (0–1), fraud risk level (LOW/MEDIUM/HIGH), contributing signals, recommended action (APPROVE/INVESTIGATE). If this API fails, claims are assessed without fraud intelligence — fraudulent claims are paid, potentially costing RM 5–10M per annum.

System API Layer

System APIs are the innermost layer — they wrap each backend system in a stable, well-defined contract that isolates Process APIs from the backend system's internal data model, API version, or technology changes. During the strangler fig migration, System APIs are the critical coexistence enabler: the Legacy PAS System API and the PolicyCenter System API expose the same logical interface, allowing Process APIs to be rerouted from legacy to modern by changing a single routing configuration in MuleSoft — without touching any consumer or Process API.

PolicyCenter System API: Wraps Guidewire PolicyCenter's REST and SOAP APIs in a stable insurance-domain data model. Exposes: createPolicy, updatePolicy, endorsePolicy, renewPolicy, cancelPolicy, getPolicy, ratePolicy. Translates between the MuleSoft canonical insurance data model and PolicyCenter's internal data model — changes to PolicyCenter's internal API (e.g., with each Guidewire quarterly cloud update) are absorbed in this System API without affecting Process or Experience APIs.

ClaimCenter System API: Wraps Guidewire ClaimCenter's APIs. Exposes: createClaim, updateClaim, assignAdjuster, approveSettlement, closeClaim, getClaimStatus, updateReserve. This API is critical-path for BNM TAT compliance: if ClaimCenter System API is unavailable, no claim action can be taken through the MuleSoft integration layer. Failover and circuit-breaker patterns must be implemented at this layer.

ISM API Adapter: Wraps ISM's NCD verification system (which may use a legacy SOAP or file-based interface) in a modern REST API. Translates incoming REST requests from the NCD Check Process API into ISM's required format, handles ISM's authentication mechanism, and transforms the ISM response into the canonical NCD data model. If ISM changes its interface specification, only this adapter needs to change — no Process or Experience APIs are affected. This is the anti-corruption layer in practice.

Legacy PAS System API (temporary): Wraps the legacy PAS in the same canonical insurance data model as the PolicyCenter System API. During the strangler fig migration (Phase 2 — indicative), Process APIs route to this System API for products not yet migrated to PolicyCenter. Once all products are migrated and the legacy PAS is decommissioned, this System API is retired. Its temporary nature must be tracked as a time-bounded architecture debt item and reviewed at each ARB meeting during Phase 2.

Principle 1 — API-First

Rationale: Enables composability, supports digital channels, allows legacy systems to be replaced without disrupting consumers. Every capability exposed as an API can be reused across multiple channels — the Quote & Bind Process API serves the Customer Portal, Agent Portal, and Aggregator API simultaneously. Without API-First, each new digital channel requires a bespoke integration to every backend system — creating an exponentially growing web of point-to-point connections that is ungovernable.

Implications: No direct database calls between systems. All integrations go through MuleSoft API-led layers. New features are API-first before UI. No system is permitted to expose functionality except through a defined and governed API. Legacy systems must be wrapped in System APIs before any new consumer can connect to them.

ARB example: A delivery squad proposes connecting a new regulatory reporting tool directly to the Oracle Financials database via ODBC to avoid the "overhead" of building an Oracle System API. The ARB rejects this proposal on Principle 1 grounds — the ODBC connection bypasses authentication controls, has no rate limiting, and creates a direct dependency that will break when Oracle is upgraded. The squad is directed to build an Oracle System API and an internal Regulatory API instead. ADR documenting this decision is published for all squads.

Principle 2 — Cloud-Native by Default

Rationale: Cloud enables elasticity, reduces capex, and provides reliability for high-volume motor and general insurance operations. Motor renewal peaks in December require 3–4x normal compute capacity — elastic cloud scaling handles this without pre-provisioning hardware that sits idle for 11 months of the year. AWS managed services (EKS, EventBridge, S3) reduce operational overhead and provide enterprise SLAs that the legacy on-premise data centre cannot match.

Implications: No new on-premise deployments approved by the ARB. AWS EKS for containerized workloads. All cloud workloads constrained to AWS Asia Pacific (Kuala Lumpur) region for BNM data localisation compliance. BNM RMiT cloud risk assessment submitted and approved before any regulated data is migrated to cloud. Disaster recovery must be cloud-native — no manual failover to on-premise DR site.

ARB example: A squad proposes deploying a new document archival service on-premise in the legacy data centre because "it's cheaper." The ARB applies Principle 2: new on-premise deployments are not approved. The squad is directed to use AWS S3 for document storage — which is cheaper per-TB than on-premise storage once hardware refresh and operational costs are factored in — and to obtain BNM RMiT confirmation that the document archival function can be hosted on AWS before proceeding.

Principle 3 — Single Integration Backbone

Rationale: Prevents integration sprawl, enforces API standards, and provides a single point of governance and visibility. Without a single backbone, each squad builds integrations using whatever tool is convenient — one uses REST point-to-point, another uses AWS Lambda, another writes direct database queries. Within 12 months, the integration landscape is unmonitorable and ungovernable. MuleSoft as the single backbone means every integration is visible, auditable, and subject to the same security and standards controls.

Implications: All integrations — internal and external — must go through MuleSoft Anypoint. Point-to-point integrations between application systems are not permitted. Any exception requires explicit ARB approval with a documented decommission plan and timeline. New API consumers must be onboarded through the MuleSoft developer portal with authentication credentials, rate limits, and consumer terms of service.

ARB example: A bancassurance partner's technical team proposes a direct REST webhook from PolicyCenter to the partner's system to "simplify the integration." The ARB rejects this under Principle 3 — a direct PolicyCenter webhook bypasses MuleSoft's authentication enforcement, rate limiting, and audit logging. The integration must go through the Bancassurance Experience API on MuleSoft. The partner's preference for simplicity cannot override the ARB's governance obligation to the Single Integration Backbone principle.

Principle 4 — Data as a Strategic Asset

Rationale: Fragmented data leads to inconsistent reporting, regulatory risk, and inability to leverage AI. When each application system holds its own data in its own schema with no integration, the same number appears differently in three different reports — the BNM return shows one premium figure, the actuarial model shows another, and the management accounts show a third. This is not a hypothetical: it is the current state of the as-is architecture, and it is the root cause of the manual reconciliation effort that consumes 5–7 business days each quarter before any BNM submission can be made.

Implications: Every domain has a named Data Owner accountable for data quality in that domain. No system produces regulatory reports directly — all go through Snowflake. Data contracts must be documented and ARB-approved for all cross-domain data flows. PII data is encrypted at rest in Snowflake and masked in non-production environments. 7-year retention policy configured in Snowflake for all regulated data domains.

ARB example: The compliance team proposes extracting BNM claims TAT data directly from ClaimCenter's database into a custom reporting tool rather than using Snowflake — citing speed of delivery. The ARB applies Principle 4: no system produces regulatory reports directly. The compliance team is directed to build the BNM TAT report as a Snowflake SQL transformation consuming the ClaimCenter event stream. This ensures the report is reconciled against the source data before submission and is auditable by BNM examiners.

Principle 5 — Design for Coexistence

Rationale: Big-bang replacements carry unacceptable risk in a BNM-regulated environment. If the entire policy portfolio is migrated from the legacy PAS to Guidewire PolicyCenter in a single cutover event, and that cutover fails or introduces critical defects, the insurer cannot issue motor policies, process renewals, or register claims. In a regulated environment, this constitutes a material operational failure that BNM must be notified of immediately. The strangler fig pattern eliminates this risk by migrating products progressively, with the legacy system remaining live as a fallback throughout the transition.

Implications: Legacy PAS and Guidewire PolicyCenter must coexist for the entire duration of Phase 2 (12 months). MuleSoft System APIs wrap both legacy and modern systems in the same interface. Traffic routing between legacy and modern is controlled by a feature flag in MuleSoft — routing changes are ARB-approved before deployment. Data reconciliation between legacy and Snowflake must be maintained throughout coexistence. Legacy PAS decommission requires formal ARB approval with evidence of complete portfolio migration.

ARB example: The Guidewire implementation squad proposes a "fast track" approach — migrating all motor comprehensive products to PolicyCenter in a single weekend cutover to accelerate the programme timeline. The ARB rejects this under Principle 5. The potential failure mode (all motor comprehensive policies unavailable for renewal during the December peak) is a BNM TAT risk and a reputational risk that outweighs the timeline benefit. The squad is directed to migrate motor comprehensive products by sub-product, with each sub-product running in coexistence for a minimum 2-week parallel run before the legacy version is retired.

Principle 6 — Build for Change — Modular Design

Rationale: Insurance business rules, products, and regulations change frequently. Monolithic designs create high change cost. BNM's motor tariff liberalisation means that premium rating rules will change more frequently in the future than they have historically. If the rating logic is hardcoded into a monolithic system (as it is in the legacy PAS), each change requires a development and testing cycle that takes months. If rating logic is configured in PolicyCenter's configurable rules engine — a modular design — changes can be made by trained configuration staff in days, with the ARB reviewing the configuration change rather than a code change.

Implications: No business logic hardcoded in infrastructure or integration layers — business rules belong in PolicyCenter (underwriting rules) or Snowflake (reporting logic). MuleSoft Process APIs must be independently deployable without affecting System or Experience APIs. Configuration changes to PolicyCenter product models and rating rules are treated as architectural changes and reviewed by the ADA before deployment. AWS EKS container architecture ensures each microservice is independently deployable.

ARB example: A squad proposes embedding the fraud scoring threshold (the score above which a claim is flagged for investigation) as a hardcoded constant in the Fraud Check Process API. The ARB rejects this under Principle 6 — the threshold should be configurable, not hardcoded, because the threshold will need to be adjusted as the fraud model matures and as the claims portfolio changes. The squad is directed to externalise the threshold as a configuration parameter stored in MuleSoft's configuration service, changeable without redeploying the API.

Principle 7 — Compliance by Design

Rationale: Non-compliance with BNM carries regulatory, financial, and reputational risk. The pattern of building features first and adding compliance controls as an afterthought invariably creates BNM risk and integration debt. BNM TAT monitoring built into ClaimCenter — not monitored externally — means that TAT breaches are caught before they become regulatory events, not after. ISM data submission automated from Snowflake — not manually extracted — means that the monthly motor data file is always accurate and timely, not dependent on a compliance officer remembering to run the extract before the deadline.

Implications: BNM TAT monitoring built into ClaimCenter workflow rules — not monitored by a separate system querying the database after the fact. ISM motor data submission generated automatically from Snowflake on a monthly schedule — no manual extraction step. AML/CFT screening integrated into the policy issuance workflow — every new policyholder screened automatically before the policy is bound. All regulatory submissions include a reconciliation check against source data before submission — no unreconciled data submitted to BNM. BNM notification required for all material IT changes — ARB maintains a register of changes that require BNM notification.

ARB example: A squad delivers the FNOL registration feature without integrating the BNM TAT clock start — the claim is registered, but the TAT monitoring dashboard is not updated until the claims handler manually marks the FNOL as complete. The ARB applies Principle 7: compliance controls must be built into the feature, not bolted on later. The squad is required to retrofit the TAT clock integration before the feature can go to production. This rework takes 3 additional weeks — a direct cost of not applying the principle at design time.

Principle 8 — Security by Default

Rationale: Security controls applied at every layer — API, data, infrastructure, and application — from day one. Security retrofitted after delivery is always incomplete and always more expensive than security built in from the start. BNM's RMiT policy mandates specific security controls for licensed financial institutions — non-compliance can result in enforcement action. In an environment where customer PII includes IC numbers, vehicle registration details, and claims records, a data breach would trigger BNM notification requirements and potential public censure.

Implications: OAuth 2.0 / JWT for all API authentication — no API key-only authentication for external-facing APIs. TLS 1.2+ for all data in transit — no unencrypted HTTP connections permitted. PII data encrypted at rest in Snowflake and S3. Zero-trust network model in AWS — no implicit trust between services in the same VPC. All access control changes to AWS IAM roles must be reviewed by the security team before deployment. Penetration testing conducted quarterly on all external-facing APIs. Vulnerability management process: critical vulnerabilities remediated within 7 days, high within 30 days, medium within 90 days — per BNM RMiT requirement.

ARB example: During an ARB review, it is discovered that the agent portal's API keys are being sent in query string parameters in the URL rather than in the Authorization header — meaning they are visible in server access logs and potentially cached in browser history. The ARB applies Principle 8: all API authentication must use OAuth 2.0/JWT. The squad is required to implement OAuth 2.0 authentication before the agent portal goes to production. The ARB also commissions an audit of all other Experience APIs to confirm they are not using the same pattern.

Principle 9 — Reuse Before Buy, Buy Before Build

Rationale: Building custom increases total cost of ownership, delivery risk, and maintenance burden. Guidewire PolicyCenter and ClaimCenter encode decades of insurance business logic — an insurer that builds a custom PAS is replicating that investment at enormous cost and risk. The principle imposes a decision discipline: before any new capability is built, the team must demonstrate that (1) no existing capability in the approved stack can be reused, and (2) no vendor product can be purchased that meets the requirement. Only if both checks fail is custom development approved.

Implications: All new capability requests must include a reuse assessment (does an existing API, Guidewire feature, or Salesforce configuration meet the need?) before the ARB will approve new development. Buy decisions must be evaluated against the approved vendor list (Guidewire, MuleSoft, Salesforce, Oracle, Snowflake, AWS, SageMaker) before external procurement is initiated. Custom-built components must include a long-term ownership and maintenance plan approved by the CTO before ARB approval. Shadow IT (Excel, Access databases, custom scripts) detected in the as-is assessment must be replaced with approved stack components — not tolerated alongside the target architecture.

ARB example: The Data & AI team proposes building a custom ML model serving infrastructure in Python on AWS EC2 because "we want full control." The ARB applies Principle 9: AWS SageMaker is the approved ML platform and provides model training, hosting, monitoring, and versioning out of the box. The custom EC2 approach would require the team to build and maintain all of that infrastructure themselves. The proposal is rejected; the team is directed to use SageMaker. The approved stack exists precisely to prevent this class of unplanned technical investment.

Principle 10 — Architecture Governance is Non-Negotiable

Rationale: Governance is the mechanism through which compliance with Principles 1–9 is verified and maintained. Without ARB oversight, delivery squads under timeline pressure will make expedient decisions that violate principles — building point-to-point integrations to avoid MuleSoft, skipping OAuth implementation to ship faster, embedding business logic in infrastructure. Each of these violations creates technical debt that is more expensive to remediate than the time saved at delivery. Governance provides the institutional memory and the enforcement mechanism that prevents the target architecture from degrading under delivery pressure.

Implications: ARB approval required for: new systems or system replacements, new integration patterns, technology choices outside the approved stack, changes to API contracts that affect consumers, data model changes to Snowflake regulated domains. All ARB decisions documented as Architecture Decision Records (ADRs) — published and accessible to all squads. ADA (Architecture Design Authority) meets fortnightly to review detailed design decisions for individual workstreams — the ARB delegates design-level review to the ADA but retains approval authority for significant decisions. Any squad that proceeds with an architecture decision without ARB approval is required to present a retrospective justification at the next ARB meeting and may be required to remediate the unapproved decision.

ARB example: A squad deploys a new integration from the customer portal to Oracle Financials using a direct AWS Lambda function — bypassing MuleSoft entirely — without ARB review, citing "urgency." When the decision is discovered in the fortnightly ADA review, it is escalated to the ARB as a governance breach. The ARB requires: (1) immediate documentation of the Lambda integration and its security controls; (2) a remediation plan to migrate the integration to MuleSoft within 60 days; and (3) a retrospective ADR explaining why the ARB process was bypassed. The squad lead is required to present the retrospective to the full ARB and the CTO. This response — transparent, proportionate, and documented — is the governance mechanism in practice.

Phase 1 — Foundation (Months 1–12, indicative)

Objective: Establish the architectural backbone on which subsequent phases depend. This phase is primarily infrastructure-focused — MuleSoft as the integration layer, AWS as the cloud platform, and Snowflake as the data platform. Governance structures (ARB, ADA, architecture principles) are also put in place during this phase. The business value may not be immediately visible to end users, but it provides the foundation that subsequent phases build on. Timeline is subject to AWS procurement, MuleSoft licensing, and internal IT resourcing.

Key Architecture Decisions — Phase 1: (1) AWS AP-Southeast-1 (KL) as the sole AWS region — all workloads constrained to satisfy BNM data localisation. ADR-001. (2) MuleSoft Anypoint Platform (CloudHub 2.0 on EKS) — EKS-hosted runtime chosen over CloudHub managed service to retain control over network egress and data residency. ADR-002. (3) Snowflake as the single data platform — no data marts or departmental databases permitted. ADR-003. (4) Legacy PAS and CMS remain live during coexistence — all traffic routed through MuleSoft from Month 1, preventing any new point-to-point integrations. ADR-004. (5) ARB approval required before any new system connection is built — enforcing Single Integration Backbone from day one. ADR-005.

Phase 2 — Core Modernization (Months 9–30, indicative)

Objective: Progress toward replacing the legacy PAS and CMS with Guidewire PolicyCenter and ClaimCenter Cloud, and begin automating regulatory reporting processes that are currently manual. This phase depends on the foundation established in Phase 1. During this period, both legacy and modern systems are expected to run in parallel under the strangler fig coexistence model — the duration of parallel running will vary based on migration complexity and team capacity. Potential outcomes include STP policy issuance, improved BNM TAT visibility, and real-time ISM NCD integration, subject to successful Guidewire configuration and regulatory readiness. Timeline will be influenced significantly by Guidewire SI availability, product model complexity, and BNM approval processes.

Key Architecture Decisions — Phase 2: (1) Strangler fig migration by product line, not by customer segment — migrating motor comprehensive first (highest volume, most standardised). ADR-006. (2) ClaimCenter TAT monitoring built in-system — TAT breach alerts generated by ClaimCenter workflow rules, not by a separate reporting layer. ADR-007. (3) ISM NCD lookup made mandatory in the rating engine — no manual override permitted without senior underwriter approval. ADR-008. (4) Parallel run for BNM regulatory reporting: 3 months of automated reports produced alongside manual reports before manual process is decommissioned. ADR-009. (5) Legacy PAS decommission plan agreed at Phase 2 close — specific decommission date and business sign-off requirements defined. ADR-010.

Phase 3 — Digital Channels (Months 24–48, indicative)

Objective: Build digital distribution and customer experience capabilities once the core insurance platform from Phase 2 is stable. This phase is intended to expose Guidewire capabilities to digital channels — aggregators, customer portal, bancassurance, and mobile — and introduce Salesforce FSC for CRM and agent management. Fraud detection via SageMaker is also targeted in this phase, contingent on sufficient labelled historical claims data being available in Snowflake. Anticipated outcomes include aggregator API integration, self-service renewals, and fraud score visibility in claims workflows. Scope and timeline are subject to Phase 2 completion stability, CRM vendor readiness, and the availability of data science resources for ML model development.

Key Architecture Decisions — Phase 3: (1) Salesforce hosted on AWS KL region via private Salesforce tenant — ensures customer PII remains within BNM's data localisation requirements. ADR-011. (2) Aggregator API rate guarantee: quoted premium valid for 24 hours — prevents customers being quoted a different premium when they return to bind. ADR-012. (3) Fraud model decisions are advisory, not automated denials — a claim cannot be declined solely on the basis of a fraud model score; human review is always required. ADR-013. (4) Customer portal built as a progressive web app (PWA) — reduces maintenance burden (single codebase for web and mobile), faster time-to-market. ADR-014. (5) All digital channel APIs must meet a 99.9% availability SLA enforced by CloudWatch alarms. ADR-015.

Phase 4 — Intelligence & Compliance (Months 42–60, indicative)

Objective: Address advanced intelligence and compliance capabilities that are not feasible earlier in the sequence, and work toward decommissioning legacy systems where migration is complete and verified. Full legacy retirement is a significant milestone — it would reduce ongoing maintenance costs and eliminate the operational risk of running ageing systems — but it should only be pursued once data migration accuracy has been confirmed and BNM notification requirements are met. AWS-native disaster recovery is also targeted in this phase to improve RTO, subject to infrastructure team capacity and DR testing outcomes. This phase is the most capacity-intensive and should be scoped based on realistic assessment of what the IT function can absorb following three prior phases of delivery.

Key Architecture Decisions — Phase 4: (1) Legacy decommission requires formal BNM notification and 90-day notice period — BNM classifies this as a material IT change. ADR-016. (2) MG-ALFA rate tables loaded to PolicyCenter via automated pipeline with actuarial sign-off gate — electronic sign-off from the appointed actuary required before rates are activated. ADR-017. (3) AML/CFT screening results stored in Snowflake with immutable audit log (no record can be deleted) — satisfies BNM AML/CFT Policy requirement for complete audit trail. ADR-018. (4) AWS multi-region DR uses active-passive model with automated failover for Tier-1 systems — RTO target 15 minutes. ADR-019. (5) On-premise data centre exit requires board approval and BNM notification as a material change. ADR-020.