01. Status, purpose and scope
This independent CAIA consultation draft proposes a practical governance baseline for banks using predictive, generative and agentic artificial intelligence. It covers internally developed systems, purchased services, embedded vendor AI, staff tools and material changes across the lifecycle. It is intended to support discussion with the Jamaica Bankers Association (JBA), member banks, supervisors and affected communities. JBA has not commissioned, reviewed, approved or endorsed this draft unless separately confirmed. No endorsement by the Bank of Jamaica (BOJ), any government or other regulator is claimed.
Jamaica is the starting jurisdiction. Regional and international sections are applicability checks and reference benchmarks, not a single Caribbean banking law or a complete legal opinion. Banks must validate current consolidated legislation, commencement, licence conditions, regulatory directions, entity scope and cross-border exposure with qualified counsel and the competent supervisor before adoption. This draft does not authorise a banking activity, relax an obligation or certify compliance.
Reading convention: “Proposed control” describes a recommendation for institutional adoption. “Existing framework” identifies law or supervisory material to examine. A bank should adopt stronger safeguards where required by its law or risk. The plain-language mode simplifies the same proposed controls; legal qualifications and source notes remain visible in both modes.
This is a proposal from CAIA to help banks use AI safely. It is a starting point for discussion with JBA, not a policy approved by JBA or a regulator. It covers AI made by a bank and AI bought from suppliers, including tools used by staff.
Jamaican law comes first. Each bank must check the rules that apply to its licences, customers and countries before using the draft. Regional examples and overseas standards do not automatically become Jamaican law. Plain-language mode keeps the same safeguards but uses simpler explanations.
02. Board accountability and responsibility
Proposed controls G1–G4. The board should approve AI risk appetite, prohibited uses, material-use approval authority and reporting. Senior management should assign an accountable business owner for each system and ensure risk, compliance, the nominated AML officer, data protection, security, legal, procurement and operations have effective challenge rights. Internal audit should independently assess the framework, not own the controls it audits. Small institutions may combine roles only where conflicts are managed and independent challenge remains credible.
Maintain one AI inventory, linked to the model register, outsourcing register and data processing records. Record purpose, customers affected, owner, supplier, model/version, data classes, jurisdictions, autonomy, risk tier, dependencies, approval, monitoring, incidents and retirement. Discover shadow AI without collecting unnecessary employee content. Report material exceptions, customer harm, overrides, control failures and concentration to the board. Do not treat a vendor assurance report as transfer of accountability.
Training should be role-specific: directors on accountability and concentration; builders on evaluation and secure design; frontline staff on verification, privacy and escalation; reviewers on effective challenge; AML teams on evidential limits and confidentiality. Record competence, not merely course attendance.
A named person must be responsible for each AI tool. The board sets the limits and receives reports on serious problems. Risk, compliance, security and privacy staff need authority to challenge its use. Audit checks the controls independently.
Keep a list of all AI tools, including supplier tools and staff use. Record what each does, its data, country, owner, version and approval. Train people for their actual jobs and check that they can spot errors. Buying AI never transfers the bank’s responsibility to a supplier.
Primary references: JM10 I1 I6
Back to top03. Classify by consequences, not product labels
Proposed controls R1–R4. Assess purpose, scale, affected rights, financial loss, reversibility, data sensitivity, autonomy, model uncertainty and interdependence. Use the highest material risk of the whole workflow, including downstream actions. A chatbot connected to payments is not low risk because its interface is conversational.
- Restricted / do not deploy: unlawful discrimination; deceptive impersonation; unapproved disclosure or training on confidential data; fabricated regulatory evidence; systems without an accountable owner; uncontrolled autonomous access to customer funds or production security settings. These are proposed bank restrictions, not a claim that every example is a named statutory AI prohibition.
- High-impact: credit eligibility/pricing/limits, account restriction or closure, fraud and sanctions interventions, AML prioritisation, biometric onboarding, collections, financial advice, employment decisions, capital/liquidity and material regulatory reporting. Require independent validation, documented human authority, legal/privacy review and formal approval.
- Controlled support: internal drafting or search using approved information. Still require permissions, source checking, confidentiality and change controls.
Reassess when data, supplier, model, geography, autonomy or intended use changes. Urgency and low purchase cost do not justify a lower tier. Compare against a non-AI alternative and document why AI is suitable.
Judge AI by what it can do to people and the bank, not by its name or price. A chat tool that can move money needs stronger controls than one that helps draft an internal note.
This proposal treats lending, account restrictions, fraud, identity checks, AML work and important financial reporting as high-impact uses. They need stronger testing and approval. Do not allow unlawful discrimination, fake evidence, confidential-data leaks or uncontrolled access to funds. Check again whenever the tool or its job changes.
04. Jamaican legal and supervisory register
Proposed control L1. Legal and compliance teams should maintain a signed applicability register rather than rely on this page as an exhaustive list. For each instrument record the authoritative version, amendments and commencement; covered legal entity and activity; specific duties; owner; control/evidence; reporting recipient and deadline; and next review date.
- Banking and supervision: Banking Services Act 2014, Bank of Jamaica Act, licence conditions and applicable BOJ Standards of Sound Practice (SSPs), including corporate governance, risk management and cyber risk. Map other regimes where the group offers securities, insurance, pensions, trust, microcredit, remittances or payment services; do not assume a banking licence covers them.
- Financial crime: Proceeds of Crime Act (POCA) and Money Laundering Prevention Regulations; Terrorism Prevention Act and its reporting-entity regulations; United Nations Security Council Resolutions Implementation Act and applicable implementing orders; Financial Investigations Division Act; current BOJ AML/CFT/CPF guidance. Preserve the separate legal tests for suspicion, sanctions and prosecution.
- Information and customer rights: Data Protection Act 2020 and applicable regulations; Credit Reporting Act and Regulations; Banking Services (Deposit Taking Institutions) (Customer Related Matters) Code of Conduct 2016; applicable consumer, contract and confidentiality duties. Confirm exact scope and complaint routes with counsel.
- Digital transactions and operations: Cybercrimes Act, Electronic Transactions Act, Payment Clearing and Settlement Act and applicable payment-system rules. Include intellectual property, employment, evidence, records and competition law where relevant.
The source register below distinguishes issued standards from consultation proposals. A law’s existence does not establish that every provision applies to every entity, or that the bank has complied.
Each bank needs its own checked list of laws and rules. It should show which business each rule covers, who is responsible, what proof is needed and when reports are due.
Start with banking and BOJ rules; money laundering, terrorism and proliferation financing; privacy and credit records; customer treatment; cybercrime; electronic transactions and payments. Add other rules for services such as insurance or investments. Check amendments and start dates. A proposal from a regulator is not the same as a rule already issued.
Primary references: JM1 JM2 JM4 JM5 JM6 JM9 JM12 JM13 JM14 JM15
Back to top05. AML, CFT, CPF and sanctions
Proposed controls F1–F6. AI may support customer due diligence (CDD), beneficial-ownership analysis, politically exposed person screening, transaction monitoring, sanctions name matching and case summarisation. It must not replace the bank’s legal judgement or weaken mandatory obligations. The nominated officer and authorised compliance staff should retain accountable decisions and filing controls. The FATF Recommendations inform national regimes; they do not themselves substitute for Jamaican legislation.
Use verified source records and timestamped official sanctions/designation feeds. Test aliases, transliteration, misspellings, common Caribbean names, entity networks and false matches. Keep sanctions freezing/reporting workflows distinct from a probabilistic fraud score; comply with legal urgency and do not delay mandatory action while seeking model certainty. A politically exposed person flag is a risk factor, not proof of wrongdoing.
Validate both missed suspicious activity and false alerts. Sample closed and unflagged cases, use typology-based challenge sets, measure backlogs and reviewer capacity, and investigate changes in detection coverage. Efficiency gains must not be measured only by alert reduction. Record evidence, model version, analyst rationale, escalation and approved overrides. Never allow AI to fabricate transaction facts, beneficial owners or source-of-funds evidence.
Protect suspicious transaction/activity reporting, investigations and requests for information. Restrict access and prevent tipping-off; do not disclose detection thresholds or protected reporting through a chatbot or appeal explanation. Legal staff should map actual FID, BOJ and other competent-authority duties, deadlines and retention rules. Preserve required records and legal holds while applying lawful deletion elsewhere.
Prevent indiscriminate de-risking: do not use geography, occupation, a remittance corridor, PEP status or a thin file alone to impose blanket exclusion. Document individual, risk-based assessment, proportionate CDD, escalation and lawful review of account restrictions/closures. Preserve mandatory sanctions and other legal prohibitions. Assess correspondent-banking dependencies and the effect of automated withdrawal on legitimate remittances.
AI can help find suspicious activity, but a score is not proof of crime. Trained compliance staff stay responsible for decisions and reports. Check real evidence, current sanctions lists, names and ownership records. Keep sanctions actions separate from ordinary fraud alerts.
Test what AI misses as well as how many false alarms it produces. Check some cases it did not flag. Saving staff time is not enough if crime is missed. Keep records of evidence and human decisions. Protect confidential reports and investigations, and never reveal information that would illegally tip someone off.
Do not reject whole groups simply because of where they live, their work, remittance route or limited credit history. Use a proportionate individual risk assessment while obeying mandatory sanctions. Follow urgent legal sanctions procedures without waiting for an AI score to become certain.
Primary references: JM3 JM4 JM5 JM6 I3
Back to top06. Digital identity, deepfakes and fraud
Proposed controls I1–I3. Test onboarding and authentication against synthetic identities, forged documents, replay attacks, voice/video cloning, coercion, account takeover and compromised devices. BOJ’s 2026 AML/CFT/CPF guidance addresses emerging technology risks, including generative-AI identity threats. Follow the applicable CDD rules; possession of a digital image or a model’s confidence score is not verified identity.
Combine proportionate independent checks, trusted document verification, controlled liveness assessment and step-up authentication. Do not rely on a single biometric, voiceprint, face match or deepfake detector. For high-risk changes to payment instructions or beneficiary details, use established independent verification, segregation of duties and transaction controls. Avoid calling back on a number supplied within the suspicious instruction.
Provide a lawful assisted route for customers who cannot pass digital checks because of disability, device limitations, documentation barriers or connectivity. Investigate demographic performance gaps. Document biometric necessity, lawful basis, security, retention and alternative routes before collection; evaluate the risk of irreversible compromise.
A convincing voice, video or identity document may be fake. Use several suitable checks, and independently verify risky changes to payment instructions. A high AI confidence score does not prove someone’s identity.
Do not depend on face or voice matching alone. Test forged documents, copied recordings and stolen accounts. Offer an assisted route for people who cannot use digital checks. Collect biometric information only where lawful and justified, protect it carefully, and check whether the system makes more mistakes for particular groups.
07. Lending, customer treatment and redress
Proposed controls C1–C4. Validate credit and pricing models for affordability, data quality, calibration, stability and unfair outcomes. Test relevant groups and intersections only with a lawful basis and privacy safeguards; small samples require explicit uncertainty rather than a fairness claim. Evaluate proxies such as postcode, device, social graph and language. Do not substitute inferred sensitive traits or unverifiable behavioural claims for relevant lending evidence.
Before use, establish understandable decision reasons based on the actual factors used, not a plausible explanation generated afterward. Review credit-bureau data access, permitted purposes, correction and dispute processes under the applicable credit-reporting framework. Provide accessible notice of material AI involvement, a way to correct information, and meaningful human reconsideration by a person with evidence, time and authority to change the outcome.
Set service standards for complaints, vulnerable customers, collections and account restrictions. Preserve legally required confidentiality, fraud controls and sanctions obligations while explaining what can lawfully be explained. This draft proposes review safeguards; it does not invent a universal statutory right to disclosure of a suspicious transaction report, unrestricted credit or reversal of a lawful freeze.
Customer-facing tools must not misstate fees, rates, product eligibility, deposit protection or contractual terms. Ground responses in approved current material and route complaints, distress and financial advice to authorised staff.
Statutory automated-decision process: map section 12 of Jamaica’s Data Protection Act for significantly affecting solely automated decisions, including its exemptions, notices, written requests and response process. The Act includes 30-day request/response periods in the relevant process; counsel must verify applicable commencement, exceptions and the exact triggering event. The proposed human-review standard here may be broader than that qualified statutory right.
Check that lending AI uses accurate, relevant information and does not unfairly disadvantage customers. Test its predictions and differences between groups without collecting data unlawfully.
Give reasons that match the real decision. Let customers correct errors and request review by someone able to change the result. A chatbot must not invent fees, promises or product terms. Explain account restrictions as far as the law allows, without exposing protected investigations. This proposal does not give customers a right to ignore sanctions or receive a loan.
Jamaica’s privacy law has a specific, qualified process for some important decisions made solely by automated means. Check its notices, exceptions and deadlines. This draft proposes broader human review; a generic complaints channel is not automatically enough to meet the law.
Primary references: JM7 JM9 JM12
Back to top08. Privacy, confidentiality and data transfers
Proposed controls D1–D5. Identify controller/processor roles, purpose, lawful processing conditions and source permissions before training, retrieval, inference or evaluation. Apply the Jamaican Data Protection Act and other applicable regimes to personal data, including prompt histories, embeddings, retrieved documents, outputs, telemetry and evaluation sets. Conduct and refresh required impact assessments; record the legal basis for sensitive data and automated decision-making safeguards where applicable.
Minimise collection, segregate tenants, enforce access at retrieval and output, encrypt data and control keys. Public availability is not automatic permission for unrestricted reuse. Prevent confidential customer information, authentication secrets and protected reports from entering unapproved public AI services. Test deletion across caches, logs, indexes and subprocessors, subject to lawful retention and holds.
Map hosting, support access, subprocessors and transfers across borders, including remote administration. Validate transfer safeguards, confidentiality obligations and regulatory access. Do not assume that Caribbean hosting, encryption or a supplier’s “no training” claim alone makes processing lawful. Contracts should bind permitted use, training restrictions, retention, incident notification, audit, access, deletion and exit. Verify technical settings and actual service behaviour.
Know what personal information AI uses, why it needs it and whether the law allows that use. Prompts, chat records, search indexes and AI answers can all contain private information.
Use only what is needed. Limit who can see it and keep it out of unapproved public tools. Check where suppliers store data and who can access it from other countries. A “no training” promise or Caribbean server location is not enough by itself. Check contracts, security and deletion, while preserving records the law requires.
09. Independent testing and model evidence
Proposed controls V1–V5. Before live use, document intended use, exclusions, training/evaluation data provenance, limitations and representative local tests. Separate development from independent validation proportionate to materiality. Assess accuracy, robustness, explainability, bias, privacy, security, drift and failure consequences. Compare with the current process and a simpler alternative. Vendor benchmarks are insufficient evidence of Jamaican performance.
Use held-out data, prevent leakage, test adverse conditions, and evaluate Jamaican English, relevant Creole usage, names, currencies, informal/seasonal income, remittances and thin credit files where appropriate. Record dataset dates, sample sizes, confidence intervals and known gaps. Assess hurricane disruption and economic regime shifts rather than assume historical stability.
Agree measurable acceptance and stop criteria before testing: material error severity, false negatives/positives, subgroup differences, ungrounded answers, disclosure failures, customer complaints, latency, availability and reviewer load. Retain test scripts, results, exceptions and approval. No universal numerical threshold is asserted here; each bank must justify tolerances against legal duties and risk appetite. Revalidate after material change and prevent silent vendor upgrades from bypassing approval.
Test AI before customers depend on it. Someone separate from its builders should challenge important systems. Compare it with today’s process and a simpler option.
Use realistic Jamaican examples, including language, names, currencies, remittances and seasonal income where relevant. Test outages and unusual conditions. Agree what counts as an unsafe result before the test. Record errors, uncertainty and missing evidence. Do not accept a supplier’s overseas benchmark as proof that the system works here. Test again after important changes.
10. Generative and agentic AI
Proposed controls A1–A5. Treat generated text, code and reasoning as untrusted until verified for the task. Ground material answers in approved sources with dates and traceable citations; refuse or escalate when evidence is missing. Assess hallucination, prompt injection, malicious retrieved documents, data exfiltration, unsafe code, impersonation and automation bias. Source citation does not by itself prove that the answer is correct.
Separate instructions from untrusted content; enforce permissions outside the model. Give agents bounded tools, least privilege, transaction limits, time limits and protected audit trails. Use sandboxed testing and allowlists. A model must not grant itself access, change its own controls or treat text in an email/document as authority to perform an action.
Require authenticated, explicit authorisation and appropriate maker-checker controls before consequential external actions. The proposed baseline prohibits uncontrolled autonomous movement of customer funds, credit commitments, account closure, regulatory filings and production security changes. Time-critical legally required sanctions/security controls must follow the approved lawful workflow, not wait for a chatbot. Provide a tested stop mechanism, deterministic fallback, recovery and post-incident review.
Payment execution controls must verify payee, amount and currency, prevent duplicate/replayed instructions, track transaction state and reconcile results. Never blindly resubmit a payment after an uncertain response. Apply scheme finality and remedy/escalation rules; do not promise that a completed payment can be reversed.
AI can make up convincing answers and follow malicious instructions hidden in documents. Check important outputs against trusted sources. A citation alone is not proof.
Limit an AI agent’s tools, access, time and transaction amounts. Enforce those limits in the software, not only in a prompt. Documents and emails cannot give it permission to act. Keep authorised human and maker-checker approval for consequential actions. Do not give it uncontrolled power over funds, accounts or regulatory reports. Test how to stop it and continue safely.
Check the recipient, amount and currency of every authorised payment. Prevent duplicates and check whether a payment completed before retrying. A payment may not be reversible. Follow the bank’s approved urgent sanctions and security procedures without waiting for a chatbot or an unnecessary extra approval.
11. Cybersecurity and operational resilience
Proposed controls S1–S4. Integrate AI into the bank’s cyber, operational-risk and business-continuity frameworks. Maintain an AI threat model and asset/dependency map; secure identities, development pipelines, model artefacts, retrieval stores and APIs. Test prompt injection, poisoning, model extraction where material, credential theft, privilege escalation, supply-chain compromise and denial of service. Conduct testing only with authorisation and safe containment.
Identify critical operations, disruption tolerances and recovery objectives. Exercise loss of the model provider, cloud region, telecoms, electricity, data feed and key staff. Include hurricanes, prolonged outages and correlated supplier failures. Maintain a workable manual or alternative channel and enough trained capacity to operate it. Check restoration integrity before resuming AI.
Record incidents and near misses, contain harm, preserve forensic evidence with privacy protections, notify the correct authorities and affected parties when required, and track remediation. Maintain a jurisdiction-specific notification matrix: this draft does not impose a single universal 24-hour or 72-hour deadline. Retest controls before restart.
Protect the AI system like other important bank infrastructure. Test attacks on its data, tools and suppliers safely and with permission.
Plan for hurricanes, power and internet loss, supplier outages and staff shortages. Know which services must keep running and how long disruption can be tolerated. Practise a manual or alternative service. When something goes wrong, stop the harm, preserve evidence, report it under the correct legal deadlines and fix the cause before restarting. There is no single reporting deadline for every country and incident.
12. Outsourcing, procurement and concentration
Proposed controls T1–T4. Assess supplier competence, ownership, subcontractors, financial viability, security, model/data provenance and service concentration. Complete any required supervisory notification, approval or non-objection before material outsourcing; do not assume this draft grants it. Map the combined exposure to a foundation model, cloud, identity provider and common data source across the bank and group.
Contracts should support regulator access, audit evidence, confidentiality, incident reporting, controlled changes, service levels, data portability, deletion, continuity and orderly termination. Allocate responsibilities clearly where the bank becomes a developer/provider through substantial modification or branding. Avoid rights that exist on paper but cannot be exercised technically.
Test provider failure, model withdrawal, price increases, licence changes and data-export limitations. Maintain an exit plan with costs, owners and credible alternatives. Assess energy/resource use, total operating cost, reviewer workload and vendor lock-in. Do not approve a dependency merely because its initial licence price is low.
Check who supplies the AI, who supplies them, and whether the bank relies too heavily on one provider. Obtain any regulatory approval the arrangement needs.
Contracts should let the bank and regulator inspect relevant evidence, protect data, control changes and respond to incidents. Practise leaving the supplier and exporting records. Budget for running costs, human review and replacement, not just the licence fee. The bank stays responsible when a supplier fails.
13. Caribbean operations and group-wide controls
Proposed control J1. Apply a common group baseline with a country/entity annex for every deployment. Identify the home and host prudential regulator, financial intelligence unit, privacy authority, consumer/competition authority and payment regulator. Record banking/secrecy law, AML/CFT/CPF rules, outsourcing, cyber reporting, data transfers, credit reporting, digital identity, sanctions implementation and legal commencement. Resolve conflicts before sharing data or deploying; escalate unresolved conflicts to counsel and competent authorities.
Regional reference points include ECCB prudential standards for institutions within its mandate; Central Bank of The Bahamas technology and outsourcing guidance; Central Bank of Barbados technology/cyber guidance; and the Central Bank of Trinidad and Tobago’s applicable risk standards. These have jurisdiction- and institution-specific scope. The Caribbean Financial Action Task Force supports regional assessment of FATF standards, not a region-wide licence or a substitute for domestic enforcement.
For Belize, Guyana, Suriname, Haiti and other markets, complete the respective local register rather than importing Jamaica’s rules. For overseas territories and French/Dutch/US-linked jurisdictions, map constitutional, territorial and parent-jurisdiction competence; do not assume all are covered by EU law or all are excluded. CARICOM and CAIA materials do not confer supervisory power.
Share non-confidential typologies, tests and training where lawful. Customer cases, biometrics, suspicious reports and identifiable incident data require separate legal authority and transfer controls. Include remittances, correspondent banking, small-market concentration, multilingual access, financial inclusion and climate resilience in regional testing.
A bank operating in several Caribbean countries needs a checked set of rules for each country and business. A shared group standard is useful, but it does not replace local law.
Jamaica’s rules do not automatically apply elsewhere. ECCB, Bahamian, Barbadian and Trinidad and Tobago standards have their own scope. Territories also have different constitutional arrangements. Share useful testing methods and training, but do not share customer records or confidential reports just because cooperation is encouraged. Test remittances, language differences, small-market risks and hurricane disruption.
14. International benchmarks and EU applicability
Proposed control J2. Use NIST AI RMF 1.0 as a voluntary lifecycle framework, supported by its Generative AI Profile (NIST AI 600-1). These are not Jamaican statutes or certification schemes. Use Basel operational-resilience principles and the FSB’s final October 2026 AI sound practices to inform governance and dependency controls, subject to domestic implementation. Consider relevant ISO standards only with an exact edition/scope and no unsupported certification claim.
EU AI Act: assess Article 2 territorial scope, including EU market/service activity and certain third-country systems whose output is used in the Union. Determine provider/deployer roles, intended purpose and classification under the current consolidated text. Natural-person creditworthiness/scoring is a key Annex III use case; the financial-fraud exception is not a general exemption for a mixed credit/fraud workflow. Assess relevant obligations on risk management, data quality, records, transparency, human oversight, robustness, fundamental-rights impact assessment and explanations where applicable. Map GDPR and DORA separately where their own scope is met.
The Commission’s current implementation guidance reports revised Annex III high-risk application from 2 December 2027, and relevant product-embedded high-risk rules from 2 August 2028, following the AI Omnibus. Do not use the original August 2026 high-risk date without checking amendments. Other duties have different start dates. Counsel must confirm the authentic amended law, transitional exceptions and each role before relying on a deadline.
For US, UK, Canadian or other exposure, assess local prudential/model-risk rules, sanctions, fair lending, consumer duties, privacy and cross-border requirements on their own legal triggers. Foreign guidance may be a useful comparator without being binding in Jamaica. Refresh fast-changing international guidance before adoption.
NIST, Basel and FSB help organise good practice, but they are not automatically Jamaican law. Do not call this draft a NIST certification.
EU rules can matter to some Caribbean businesses with relevant EU activity or AI outputs used there. Check the exact scope and the bank’s role. Credit scoring needs particular care; a fraud exception does not excuse a combined lending system. The EU high-risk timetable has changed, and different duties start at different times. Check the current law, including privacy and resilience rules. Other countries’ rules need their own checks too.
Primary references: I1 I2 I5 I6 I7 I8
Back to top15. Control-to-evidence crosswalk
The following is an implementation aid, not proof of equivalence or compliance. NIST functions are connected, iterative activities, not a compulsory sequence.
| Framework lens | CAIA control groups | Evidence to retain |
|---|---|---|
| NIST Govern; FSB governance | G, L, T | Board approval, roles, inventory, legal register, supplier register, training and audit |
| NIST Map; FSB materiality | R, D, J | Purpose and alternatives, impact assessment, affected groups, data flows, jurisdiction and role analysis |
| NIST Measure; FSB performance | V, C, I, F | Independent validation, local test sets, uncertainty, fairness/accuracy evidence, AML coverage and override review |
| NIST Manage; Basel resilience | A, S, T | Access/action boundaries, monitoring, incident response, fallback/exit exercises and change approval |
| NIST GenAI Profile | A, D, V, S | Grounding checks, confabulation and injection tests, privacy controls, misuse testing and escalation |
| EU AI Act, only where applicable | J2 plus G–V | Scope/role/classification memo; required documentation, assessment, registration, oversight and post-market duties as legally applicable |
Assign each evidence item an owner, version, retention rule, access level and review date. Record gaps explicitly. A crosswalk is not an audit opinion.
Keep proof that controls work. Governance needs approvals and named owners. Risk assessment needs a clear purpose, data map and legal checks. Testing needs results, sample sizes and known gaps. Safe operation needs monitoring, incident plans and practised alternatives.
Give each record an owner and review date. Mapping a control to NIST, Basel, FSB or EU topics does not prove compliance or mean that the organisation has passed an audit.
16. Approval, monitoring and retirement gates
Proposed controls P1–P4. Before production, require a completed inventory entry; documented legal/privacy/AML assessment; authorised data and suppliers; independent validation for material uses; accepted residual risk; trained reviewers; customer notices and complaint route; security tests; incident contacts; and tested fallback/exit. The business owner, risk/compliance and designated approval authority should sign within their mandates. Do not launch where a critical legal, security, fairness or resilience issue remains unresolved.
Monitor both technical performance and real outcomes: customer harm, missed financial crime, erroneous restrictions, explanation quality, complaints, overrides, data incidents, downtime, costs and staff burden. Use appropriate denominators and time windows; distinguish detected errors from escaped harms. Do not present estimated savings as realised benefits. Define pause thresholds and give the operational owner authority to stop use.
Keep a controlled change log, approve material updates, and review at least on the bank’s agreed schedule and after incidents or law changes. Retirement requires revoking access, preserving legally required evidence, deleting data lawfully, notifying dependent teams and confirming replacement/fallback. Publication of this draft does not start an implementation deadline.
Check applicable regulatory engagement for material internally developed AI changes and new products/channels as well as outsourcing. Complete required notifications, approvals or non-objections under the relevant legal framework before implementation.
Do not go live until the bank has checked the law, data, supplier, tests, training and fallback. Important problems must be fixed first, and the right people must approve.
Measure real customer and operational outcomes, not just model accuracy or claimed savings. Set clear reasons to pause a system. Keep track of changes and test major updates. When retiring AI, remove access, preserve required records, delete other data lawfully and make sure customers can still receive the service.
Check whether a new product, channel or major internal AI change needs regulatory notification or approval. This is not only an outsourcing question.
17. Suggested adoption plan and consultation questions
A bank may use the following indicative phases after an authorised adoption decision, with resources and timing adjusted to its obligations and risk. These are proposed milestones, not commitments by JBA or any institution.
- Establish: appoint sponsors, inventory AI, map laws and suppliers, stop unapproved sensitive-data processing, prioritise material risks and agree funding.
- Validate: complete impact assessments and local test sets, train reviewers, approve procurement terms and complaint/incident pathways, and run bounded pilots with public, synthetic or appropriately authorised data.
- Operate: review pilot evidence, approve only uses meeting gates, monitor outcomes and exercise continuity/exit. Expand only when supported by evidence.
- Review: assess changes in law, suppliers, models and customer outcomes; publish an appropriate non-confidential accountability summary.
Questions for JBA and wider consultation: Which controls should be minimum requirements and which should vary by institution size? What shared testing and training can reduce cost without weakening safeguards? How should meaningful human review work at transaction speed? Which legal/operational conflicts need regulator clarification? What are the priority Jamaican-language, inclusion and SME-credit tests? What evidence and supervisory engagement are needed before pilots? Who is missing from the consultation?
Invite banking, AML, privacy, cyber, consumer, disability, labour, SME and academic perspectives through an agreed consultation process. JBA participation and any publication of its views require confirmation. This page does not submit the draft to JBA or collect confidential banking information.
Start by finding the AI already in use and the biggest risks. Then test a few bounded uses, train people and practise handling complaints and failures. Expand only when the evidence supports it.
CAIA proposes discussing the draft with JBA and others, including customers, small businesses, disability groups and specialists. Key questions are which safeguards everyone needs, where smaller banks need support, and how to test local language and inclusion. These are suggestions for consultation, not promises or endorsement by JBA.
18. Working templates and glossary
Use-case record: ID; purpose; owner; affected people; model/supplier/version; permitted actions; risk tier and rationale; data/locations; applicable laws; baseline alternative; impact assessment; independent validator; acceptance thresholds; evidence links; approval; monitoring; pause/recovery; next review.
Incident record: detection/time zone; system/version; affected service; observed versus suspected harm; containment; evidence custodian; confidentiality; legal notification decision/recipient/deadline; accountable owner; customer remedy; root cause; retest and restart approval. Do not enter sensitive case details into this public page.
Country annex: legal entity/licence; home/host supervisors; FIU/privacy authorities; current instrument/version/commencement; duty and control; outsourcing approval; data-transfer mechanism; reporting/retention; customer complaint route; unresolved conflict; counsel sign-off date.
Glossary: AML: anti-money laundering. CFT/CTF: combating/countering the financing of terrorism. CPF: countering proliferation financing. CDD: customer due diligence. PEP: politically exposed person. FIU: financial intelligence unit. GenAI: AI that generates content. Agentic AI: AI connected to tools that can take actions. Drift: a change in data or performance over time. Human oversight: effective review with authority to intervene, not automatic acceptance. NIST: US National Institute of Standards and Technology. FSB: Financial Stability Board. FATF/CFATF: global/Caribbean financial action task forces.
For every tool, record what it does, who owns it, what data it uses, its limits, tests and approval. For an incident, record what happened, who was affected, what was done and which reports are legally required. For each country, record the correct authorities and rules. Keep private case information out of this public page.
AML means preventing money laundering. CFT or CTF means countering terrorism financing. CPF means countering proliferation financing. CDD means checking customers. GenAI creates content; agentic AI can use tools to act. Human oversight means someone can genuinely question and stop the system.
19. Banking-context and stakeholder assessment
Assessment purpose. Test both policy alignment and practical usefulness before adoption, before a material AI use goes live, and after material change. Start with the banking problem, affected people and current process; do not score a generic AI policy without a defined institution, product, jurisdiction and use case.
- Scope the case: identify deposit/lending/payment/remittance/compliance activity, legal entities, channels, customers, staff, suppliers, autonomy, data, legal duties and business constraints. Document the non-AI baseline and the benefit sought.
- Map affected stakeholders: include frontline and operational staff, reviewers, managers, directors, the bank/group, JBA or other associations, customers and excluded applicants, SMEs, vulnerable people, supervisors and affected communities. Record who participated, conflicts of interest and missing voices. An association cannot consent for every member or customer.
- Review evidence: compare the draft and actual workflow with the current legal register, NIST/FSB controls and local operational tests. Interview staff, run customer comprehension/accessibility tests, sample decisions and complaints, and test adverse scenarios. Use synthetic or properly authorised data.
- Rate each criterion: 0 = absent/contradicted; 1 = documented but not tested; 2 = implemented with limited evidence or important gaps; 3 = tested with representative evidence and accountable monitoring. Mark unknown separately; allow not-applicable only with written legal/risk justification. Record evidence, assessor, stakeholder feedback, uncertainty and improvement owner.
- Decide and remedy: no aggregate score can override a critical failure. Block live use for unresolved illegality, missing authority/data basis, material discrimination, ineffective review, unsafe money/account actions, uncontained data leakage or failed critical-service fallback. Set actions, responsible owners and review dates; retest before approval.
| Affected group | What to assess | Evidence and measures |
|---|---|---|
| Individual staff and reviewers | Clear permitted uses; competence; realistic workload; ability to challenge and report problems without retaliation | Task-based training tests, time/queue studies, error/override review, confidential staff feedback; no hidden surveillance creep |
| Managers and directors | Decision authority, escalation, understandable risk reporting and adequately funded controls | Approval/incident exercises, exception ageing, board reporting, resource and accountability review |
| Bank and group | Legal fit, measurable value, model/supplier concentration, auditability and continuity | Signed legal map, baseline comparison, total cost, material incident/availability measures, independent validation and exit tests |
| JBA and other associations | Usable common baseline with proportionate implementation and lawful cooperation | Member feedback by size/business model, shared template trials, training burden and unresolved divergence log; no sharing of competitively sensitive or protected customer information |
| Customers, applicants and SMEs | Accuracy, fair treatment, comprehensible reasons, privacy, accessibility, effective complaint/review and real service benefit | Customer comprehension tests, correction/reconsideration outcomes, false restriction and complaint rates, access completion, subgroup uncertainty and non-digital route tests |
| Supervisors and public interest | Traceable compliance, financial-crime effectiveness, resilience and appropriate transparency | Reconstructable decisions, reporting tests, AML coverage, continuity exercises and lawful non-confidential accountability reporting |
Banking scenario pack: a thin-file SME loan; a customer wrongly matched to a sanctions name; a deepfake payment instruction; a staff copilot leaking a protected report; a hurricane-related provider outage; and a vendor update that changes credit outcomes. For each, measure the outcome for the customer, staff, manager and bank, identify the lawful decision-maker and test recovery/appeal. Include successful uses as well as failures.
Consultation record: clause/control ID; stakeholder and role (with consent for attribution); proposed change; banking scenario; evidence; legal/practical impact; severity; accepted/modified/deferred/rejected disposition with reason; owner and next review. Publish an appropriate anonymised response summary after an authorised consultation. Do not imply responses have already been obtained. Have legal, AML, customer, security and operational reviewers challenge one another; disclose that internal or automated review is not independent human-expert certification.
Judge this policy against real banking tasks and the people affected. First define the bank, service, country, data and problem. Compare AI with the service people receive today.
Ask staff whether the rules are clear and workloads realistic; managers whether they can act on problems; banks whether the controls work and costs are justified; associations whether members can use the common approach; and customers whether the service is fair, understandable and accessible. Include people who were refused service or cannot use digital tools.
Score each test from 0 (missing) to 3 (tested with good evidence). Keep unknowns separate. A high overall score cannot excuse an illegal or unsafe system. Test examples such as a wrongly frozen account, fake payment instruction, thin-file business loan and hurricane outage. Record each suggested improvement, who owns it and whether it was accepted. Do not claim stakeholder support before consultation happens.
20. Useful banking applications and bounded pilots
Assess opportunities alongside harms. Candidate pilots include approved-source staff knowledge search, document extraction with field-level checking, customer-service drafting with human review, accessibility/translation assistance, fraud investigation support and cash-flow/SME analysis. Benefits are hypotheses until measured; no use case is approved by this page.
For each candidate, record who benefits, who bears extra work or risk, the non-AI comparator, data and legal prerequisites, testable value measures, operating cost, exclusion risks and stopping conditions. A knowledge-search pilot might measure verified answer accuracy and staff time; extraction might measure critical-field errors and correction time; accessibility support might test comprehension with relevant users; financial-crime support must measure missed cases and false interventions, not merely fewer alerts.
Begin with public, synthetic or appropriately authorised data in a bounded environment. Do not graduate to live customers, consequential decisions or new countries solely because a demonstration looks convincing. Apply the relevant risk tier, stakeholder assessment and production gates. Consider whether improving the existing process would deliver the same benefit with less complexity.
AI may help staff find approved information, check documents, draft replies, improve accessibility and investigate fraud. These are ideas to test, not approved projects or proven savings.
For each idea, ask who gains, who takes the risk and whether a simpler improvement would work. Measure real accuracy, time, cost and customer experience. Start in a controlled test using lawful data. A good demonstration is not enough to justify using AI on real customers or important decisions.
21. Prudential, treasury and financial reporting
Proposed controls B1–B4. For AI used in expected credit loss/provisioning (including IFRS 9 where applicable), valuation, capital, liquidity, asset-liability management, stress testing, treasury/trading or regulatory returns, reconcile inputs and outputs to controlled books, approved data and reporting definitions. Document assumptions, scenario design, model limits, expert overlays and uncertainty; retain finance/risk ownership and independent validation/backtesting. Obtain any applicable supervisory model approval or change authorisation.
Do not substitute invented GenAI assumptions or estimates into accounting or regulatory figures. Ensure authorised finance/risk staff can reconstruct calculations and approve material judgements. Test extreme but plausible conditions, correlated exposures and liquidity effects; distinguish scenario estimates from realised results.
For trading or treasury automation, enforce position, credit, liquidity and execution limits outside the model, monitor market conduct and manipulation risks, and use controlled stop/fallback arrangements. Separate proposal generation from execution authority. Reconcile positions, confirmations and settlements and investigate mismatches promptly. Assess customer suitability and advice obligations wherever the use extends to client recommendations.
AI must not invent numbers for the bank’s accounts, capital, liquidity or reports to regulators. Check its work against trusted records and approved definitions. Finance and risk staff remain responsible for assumptions and important judgements.
Test forecasting and stress models independently, including difficult market conditions. Obtain any required regulatory approval. For trading, enforce exposure and transaction limits outside the AI, prevent misconduct, and reconcile trades and settlements. Advice to customers also needs the appropriate suitability and conduct safeguards.
22. Sources and legal status
Primary-source register checked 4 November 2026. The draft distinguishes existing law, supervisory standards, consultation proposals, foreign rules where applicable and voluntary benchmarks. The controls labelled “proposed” are CAIA recommendations, not newly enacted duties.
Verify current consolidated law and commencement; institution/licence scope; local complaint and notification routes; exact EU amended provisions and transitional rules; any later BOJ finalisation of consultations; and every country annex. Confirm customer/staff consultation and independent specialist review. No claim of exhaustive legal coverage or independent expert certification is made.
Jamaican legislation gateway. BOJ warns hosted texts may not be complete/current; verify consolidated law, amendments and commencement.
Existing banking legislation, as amended. Entity/activity-specific legal review required; this PDF alone is not a consolidated-law assurance.
Supervisory guidance gazetted 17 June 2026. Includes emerging technology and GenAI identity risks in Appendix IX. Read alongside applicable law, not instead of it.
Existing law; consult subsequent amendments and Money Laundering Prevention Regulations via JM1.
Existing law. Hosted consolidation is through 2013; later amendments and reporting-entity regulations require checking through JM1.
Existing Jamaican framework; check implementing orders, designations and reporting-entity regulations. Foreign sanctions lists have separate nexus/contractual questions.
Existing law with section-specific applicability/commencement checks. Section 12 qualified automated-decision rights; sections 23/24 processing conditions; section 31 overseas transfers. Section 21(3) includes a 72-hour Commissioner reporting provision for relevant breaches/contraventions, not a universal deadline for every AI incident.
Check actual issued regulations, including 2024 instruments. Exact commencement and current DPIA submission requirements, including section 45, remain matters for counsel/OIC verification; do not rely on an unsigned 2023 draft.
Existing credit-reporting framework; check the Act, Regulations, permitted purposes, accuracy, disclosure and dispute duties.
Issued supervisory standard, effective 21 November 2025, with one-year conformance for existing institutions ending 21 November 2026. It states it does not itself have force of law, while nonobservance can inform unsafe/unsound-practice action. Check scope, including separate treatment of foreign-bank branches.
Issued supervisory standard; use this rather than treating the earlier consultation as final.
Existing customer-conduct instrument. Not a claim of a comprehensive financial-consumer-protection statute.
Existing framework. Do not treat proposed replacement/expanded payment legislation as enacted without checking.
Existing electronic-transactions framework; AI does not remove authentication, attribution and evidentiary requirements.
Consultation proposal, not represented as final or binding. Check whether finalised before adoption.
Consultation proposal, not represented as final or binding. Existing duties continue separately.
Regional comparator applicable to institutions within the relevant ECCB framework; verify local scope and current status.
Local supervisory materials, including technology and outsourcing; not Jamaican rules.
Includes Technology and Cyber Risk Management Guideline issued March 2026. Confirm local entity scope.
Voluntary benchmark. AI RMF 1.0 and related resources; NIST reports revision work underway. Not a certification.
Voluntary companion profile published 2024, informing GenAI-specific assessment and controls.
International standards implemented through national frameworks. Check current revisions; distinguish domestic law, supervisory expectations and foreign requirements.
Risk-based digital identity guidance, not automatic approval of a specific identity product.
International supervisory benchmark, March 2021; local implementation and scope must be checked.
Final international good-practice report, replacing the June consultation as the reference here. Not itself Jamaican law.
Binding EU regulation where applicable. Counsel must inspect the authentic amended instruments and specific scope/role/classification; direct automated retrieval of the consolidated page was unavailable during this review.
Official explanatory source checked 4 November 2026, reflecting July 2026 AI Omnibus and revised high-risk dates. Guidance is not a substitute for the legal text.
Attribution and reuse
You may use and adapt the original CAIA guideline text with clear attribution to Adrian Dunkley and the Caribbean AI Association. Identify your changes, retain source version and draft status, and state your adaptation’s status accurately. Adaptation does not imply CAIA, author, JBA or regulator endorsement. This permission does not license third-party documents, names or logos.
Suggested credit: “Adapted from Draft AI Guidelines for Banking, v0.1 (4 November 2026), lead author Adrian Dunkley, Caribbean AI Association.”