Policies
The rules the platform runs on: the PDPA, banking secrecy, the Bank’s Model Risk Management policy, RMiT and third-party risk, each with the platform control that enforces it.
LifecycleAll nine stages
100%
every catalogue asset carries a classification
96%
4 Tier 2 models overdue for revalidation
12/12
all High-risk models in production covered
24 months
immutable, queryable, scoped by business unit
Data residency by construction
Residency is not a clause in a contract here: customer data, the compute that trains on it and the inference served from it all sit in Google Cloud Malaysia, and the platform has no path that moves production data out.
- Production and customer data stay in Google Cloud Malaysia
- Singapore is for platform build, testing and non-sensitive pilot data only
- No customer data in prompts; Gemini is served on Vertex AI in-region
- Every access to customer data is purpose-bound, attributable and logged
Policies in force
Each policy is a live constraint in the validation and access paths, not a document filed elsewhere.
Personal data protection
Personal Data Protection Act 2010 (PDPA), as amended 2024
Every asset carries a classification (Internal / Confidential / Strictly Confidential) assigned at registration and re-checked on each version. Access to personal data requires a stated purpose, a bounded period and an accountable business unit. Purpose limitation is enforced through entitlements: a grant covers the declared use only, and reuse for a new purpose is a new request.
- ✓ Classification assigned at registration, reviewed quarterly
- ✓ Purpose-bound, time-bound entitlements
- ✓ PII scanning on every dataset load and every GenAI prompt
- ✓ Privacy impact assessment before a High-risk model goes live
Banking secrecy
Banking secrecy under the Financial Services Act 2013
Customer information is secret by default. Strictly Confidential data, meaning anything that identifies a customer or their accounts, is visible only to named grantees for a stated purpose, with the data owner's consent recorded through the Data Governance Committee. Derived assets (models, features, embeddings) inherit the strictest classification of their training data unless a documented de-identification review lowers it.
- ✓ Data owner consent for customer-level data
- ✓ Classification inheritance for derived models
- ✓ Masking by default; unmasked fields named in the grant
- ✓ Watermarked, logged downloads
Model Risk Management policy
Alliance Bank policy · owned by Model Risk Management, Group Risk
Models are tiered by materiality (Tier 1 / 2 / 3). Model Risk Management, as the second line, validates every model independently before first use, sets the monitoring thresholds, and revalidates on a cycle set by the tier. Credit decision models are fairness-tested and carry a documented explainability method for adverse outcomes. A model is replaced only after a champion–challenger comparison. The approach draws on BNM's work on responsible AI in the financial sector and Malaysia's National Guidelines on AI Governance and Ethics.
- ✓ Model tier set at intake from a structured questionnaire
- ✓ Independent validation before first use; periodic revalidation
- ✓ Fairness tests on credit decisions, re-run on every retrain
- ✓ Explainability for adverse outcomes, to the customer and the RM
Technology risk and change
BNM Risk Management in Technology (RMiT)
A model in production is a system under Group IT's change management, not a notebook. Promotion needs a change record with test evidence and a rollback plan; a High-risk model also needs Model Risk Management approval on record. Owners carry versioning duties while the model serves traffic: a changelog per release, a retrain SLA triggered by measured drift, and a notice period before an endpoint is withdrawn.
- ✓ Change record with rollback plan for every production promotion
- ✓ Retrain SLA: proposal within 10 working days of PSI > 0.25, shipped within 45
- ✓ Deprecation notice: 90 days for production endpoints, 30 for staging
- ✓ Named fallback before any model is suspended or withdrawn
Third-party and outsourcing risk
BNM Policy Document on Outsourcing · Alliance Bank third-party risk policy
Vendor models and data providers are approved by Group Risk before they enter the catalogue. Due diligence covers where data is processed, sub-processors, model provenance and exit terms. A vendor that would touch customer data needs the data owner's sign-off and an outsourcing assessment. Vendors are paid under licence; they are monitored like any in-house model.
- ✓ Vendor approval before first use, with a review date
- ✓ Data-location terms: production data stays in the MY region
- ✓ Licence scan on every vendor artefact
- ✓ Same validation and monitoring as in-house models
Controls in force
Every policy duty maps to a mechanism and a screen. 7 of 12 run unattended, the rest hold a deliberate human checkpoint.
| Duty | Policy | Enforcing control | Visible in product | Mode |
|---|---|---|---|---|
| Purpose limitation | Personal data protection | Gated access request with a stated purpose and bounded duration | Asset card · Access monitoring | human gate |
| Entitlement expiry | Personal data protection | Renewal nudge at 30 days, endpoint revocation on lapse | Entitlement expiry panel · Automation rule | automated |
| PII detection | Personal data protection | PII scan on every dataset load and GenAI prompt; steward sign-off on any hit | Publishing pipeline · Dataset health score | automated |
| Customer data consent | Banking secrecy | Data owner consents to every grant on customer-level Strictly Confidential data | Governance · Approval queue | human gate |
| Classification inheritance | Banking secrecy | Derived asset inherits the strictest upstream tier and gates itself | Model card lineage · Automation rule | automated |
| Data residency | Technology risk and change | Egress scanner blocks and quarantines transfers outside Google Cloud Malaysia | Access monitoring · flagged events | automated |
| Independent validation | Model Risk Management policy | Validation gate: registration blocked until Model Risk signs the opinion | Publishing pipeline stage 4 | human gate |
| Fairness on credit decisions | Model Risk Management policy | Fairness suite re-run on every retrain, results attached to the version | Model card metrics · MLOps pipeline | automated |
| Drift & retrain SLA | Technology risk and change | Weekly PSI and CSI job opens a pre-filled retrain proposal for the owner | MLOps drift posture · Automation rule | automated |
| Deprecation & fallback | Technology risk and change | Retirement review with a named replacement and consumer notice | Governance · Retirement tab | human gate |
| Vendor approval | Third-party and outsourcing risk | Vendor artefacts blocked from the catalogue until Group Risk approves the vendor | Publishing pipeline · Asset card | human gate |
| Accountability record | All policies | Immutable audit entry for every access, validation and governance decision | Governance · Audit log | automated |
Enforcement is automated where it can be
Policy that depends on someone remembering to apply it is not policy. Classification inheritance, PII scanning, egress blocking, entitlement expiry, and drift-triggered retrain proposals all run unattended on the platform: 7 of 12 controls on this page fire without a human in the loop, and every firing writes to the audit trail. The rules themselves are inspectable and toggleable in the Triggers and rules.
What stays human is deliberate, not residual: consenting to use of customer-level data, signing a model's validation opinion, approving a production change, approving a vendor, and suspending a model other teams depend on. Those carry accountability that cannot be delegated to a rule, so the platform routes them to the data owner, Model Risk Management, Group IT or Group Risk by name, and Internal Audit reads the record afterwards.