# Compliance Operations Procedures Last reviewed: 2026-07-01 Owner: Head of compliance / MLRO Approvers: Legal, risk, privacy, security, operations Review cadence: At least annually and after a regulatory, jurisdiction, provider, product, or material rule change These procedures define the repository-supported operating model for KYC, AML, sanctions, fraud, complaints, and suspicious-activity escalation. They are not a substitute for jurisdiction-specific legal advice, regulatory filing rules, or a licensed compliance function. Before launch, the accountable compliance officer must approve a control register containing applicable laws, filing authorities, deadlines, retention, thresholds, and provider SLAs for every target market. ## Roles And Separation Of Duties | Role | Responsibilities | Must not do | | --- | --- | --- | | Compliance analyst | KYC/manual review, screening disposition, case evidence, EDD collection | File a regulatory report without delegated authority | | MLRO or delegated reporting officer | Suspicion decision, SAR/STR approval/submission, regulator liaison | Delegate accountability to an automated score | | Fraud/risk analyst | Transaction/card/account-takeover investigation and containment recommendation | Override sanctions or AML closure decisions | | Support | Receive customer contact, verify identity through approved process, create/route complaint or incident case | View SAR/STR material, disclose screening logic, or change money/verification outcomes | | Operations | Provider contact, payment holds, report ingestion, reconciliation and execution evidence | Resolve a compliance hit without compliance approval | | Privacy/security | Data access, breach, retention, evidence storage and privileged-access controls | Decide customer financial-crime risk alone | Production roles use least-privilege scopes, MFA/step-up, JIT elevation where needed, and quarterly access review. High-risk rule/config changes require a different maker and checker. Case access is need-to-know and all viewing, export, notes, attachments, status changes, and decisions must be auditable. ## Case And Evidence Standard Every compliance or fraud case must contain: - stable customer, screening, transaction, provider, and related-case references - alert source, detection time, jurisdiction/entity, risk tier, priority, owner, assignee, SLA/due date, and current status - facts and evidence separated from analyst interpretation - provider decision/raw-payload reference with sensitive fields protected - searches/checks performed, timestamps, result, and data source/version - customer/provider contact history and approved evidence attachments with hash - decision, rationale, reviewer/approver, date, follow-up/periodic-review date - regulatory-report decision and reference, restricted from support/customer views Do not paste secrets, passwords, OTPs, recovery codes, clear PAN/CVV, private keys, or unnecessary raw PII into notes. Attachments use encrypted private storage, malware scanning, checksums, classification, retention, and short-lived access. ## KYC And Identity Verification ### Intake 1. Collect only approved identity/profile fields and display the current privacy notice and purpose. 2. Validate required fields, age/product eligibility, country/jurisdiction, and document metadata. The application stores evidence metadata and provider references; production evidence retrieval must use the contracted provider or restricted evidence store. 3. Confirm consent/lawful-basis records as required by the jurisdiction control register. Do not collect unsupported document types. ### Verification 1. Submit to the configured identity provider with a unique customer and provider verification reference. 2. Accept decisions only from authenticated provider APIs/callbacks. Deduplicate provider event IDs and preserve decision history. 3. Treat `pending` as no approval. Route `manual_review` and inconclusive/mismatched evidence to an assigned compliance case. 4. `verified` permits only products allowed by jurisdiction, risk tier, sanctions, age, and feature configuration. It does not override AML or sanctions controls. 5. `rejected` records a factual reason category and approved customer-safe wording; do not expose provider rules or sensitive match details. ### Manual Review And EDD - Compare identity, liveness, address, document validity, duplicate identity, and provider evidence according to the approved KYC policy. - Start EDD for high-risk country/customer, PEP or adverse-media signal, complex ownership, unusual source of funds/wealth, material mismatch, or MLRO direction. - Record required evidence, due date, evidence source, decision, reviewer, and next review. Expired evidence cannot support approval. - A high-risk customer requires independent approval defined in the role matrix. ### Periodic And Event-Driven Review Schedule review by risk tier in the approved control register. Trigger earlier review for identity/profile change, expired evidence, new PEP/adverse-media or sanctions signal, material transaction change, account takeover, provider alert, law/jurisdiction change, or repeated complaints/fraud indicators. ## Sanctions, PEP, And Adverse Media Screen at minimum: - customer onboarding and before approval - beneficiary/payment creation and again immediately before held payment release - material customer identity change - scheduled ongoing monitoring using the provider's refreshed datasets - crypto addresses/transactions when crypto is enabled Potential-match procedure: 1. Prevent execution or place the relevant workflow on review hold according to the approved sanctions policy. Do not silently mark the person as confirmed. 2. Open/assign a restricted AML case with provider list/version, match fields, score, customer identifiers, transaction references, and timestamps. 3. Compare identifiers such as name, date/place of birth, nationality, address, aliases, entity/ownership, and official list reference. Apply only documented provider and policy matching rules. 4. Escalate likely/confirmed matches immediately to the MLRO/sanctions officer. 5. Release a false positive only with rationale, reviewer, list/version, and any approved future suppression identifier. Never suppress solely on name mismatch. 6. For a confirmed match, maintain the hold/block, preserve evidence, follow legal reporting/freezing instructions, and restrict communications to approved text. Do not tell a customer they are the subject of a sanctions, PEP, adverse-media, AML, or regulatory-report investigation unless legal/compliance explicitly approves the communication. ## AML Transaction Monitoring 1. Ingest relevant customer, transfer, card, FX, crypto, login, device, limit, beneficiary, and provider signals with stable references and timestamps. 2. Apply versioned, approved rules/models. Record input factors, output score, decision, and rule/model version; do not rely on an unexplained score alone. 3. Route review/block decisions to a case with priority and SLA. Link related alerts instead of closing duplicates without analysis. 4. Establish expected activity using KYC/customer risk; assess amount, velocity, pattern, counterparties, geography, channel, source/destination, and historical behavior. 5. Document disposition as false positive, insufficient evidence/continued monitoring, customer restriction/exit recommendation, or suspicion escalation. 6. Feed confirmed false-positive/true-positive outcomes into tuning records. Rule changes require testing, maker-checker approval, effective date, and monitoring. Quality review samples closed alerts by analyst/rule/outcome and checks timeliness, evidence, consistency, override rate, false negatives, false positives, and customer impact. Backlogs or SLA breaches trigger compliance leadership review. ## Fraud Operations Fraud signals include account takeover, impossible/new-device behavior, beneficiary change, payment/card/FX velocity, limit evasion, mule indicators, card disputes, provider alerts, identity duplication, and crypto address risk. 1. Contain proportionately: revoke sessions, require step-up, freeze card, hold the payment, disable a route, or restrict the account. Do not destroy evidence. 2. Create a `fraud_review` case linking security/risk events and all affected money movements. Record whether external execution is confirmed, failed, or unknown. 3. Check authentication timeline, session/device/IP signals, beneficiary changes, provider references, ledger journals, disputes, and customer contact. 4. Coordinate with finance/operations for reversals or recalls. Never promise recovery before provider outcome and legal rights are known. 5. Escalate suspected money laundering, organized fraud, sanctions evasion, or mule behavior to the MLRO without alerting the customer to that escalation. 6. Close only after containment, customer/account remediation, financial outcome, notifications, residual monitoring, and control improvements are recorded. ## Suspicious Activity And SAR/STR Escalation Any employee or system may raise suspicion. Only the MLRO/delegated reporting officer decides whether and how to file. 1. Analyst marks the AML case escalated, captures a concise factual basis, and identifies related customers, accounts, transactions, dates, amounts, providers, and evidence. Restrict access immediately. 2. Record whether urgent containment or consent/defence-against-money-laundering process may apply, but follow jurisdiction-specific legal instruction. 3. MLRO reviews the complete chronology, KYC/risk, transaction analysis, screening, customer explanation where appropriate, and linked cases. 4. Create a restricted regulatory-report record as `draft`; use `in_review` for independent/required review. Narrative separates known facts from inference. 5. Submit only through the approved authority channel and within the deadline from the jurisdiction control register. Record filing authority, reference, submitter, time, and retained receipt; mark `submitted` only after confirmation. 6. If no report is filed, record the MLRO decision and rationale in the restricted case. Do not erase the escalation. 7. Set post-filing monitoring, customer/product restriction, account-exit, law enforcement request, and review actions as legally directed. Tipping-off prevention: - SAR/STR existence, deliberation, narrative, authority contact, and thresholds are excluded from customer/support views and ordinary exports. - Customer communications use neutral operational wording approved by compliance. - Access/export to report records is monitored and periodically reviewed. ## Customer Complaints A complaint is any expression of dissatisfaction requiring a response, regardless of channel or whether the customer uses the word "complaint." 1. Create a `customer_complaint` case with received time/channel, customer, product/transaction, issue, requested outcome, jurisdiction, vulnerability or accessibility needs, owner, and the applicable response deadline. 2. Acknowledge using the legal-approved template and provide case reference, expected process, and accessible contact channel. 3. Preserve recordings/messages, disclosures, rate/fee/terms version, provider and ledger evidence, support contacts, and decisions. 4. Assign an investigator sufficiently independent from the disputed action. Financial, privacy, fraud, discrimination, vulnerability, and regulatory issues route to the corresponding specialist owner. 5. Investigate fair customer outcome, root cause, similar affected population, and remediation. Financial adjustments use approved ledger workflows. 6. Send a clear final response with findings, remedy, effective date, and external escalation/ombudsman rights required by jurisdiction. Do not expose restricted AML/SAR/security details. 7. Close only after response/remedy delivery evidence and root-cause action are recorded. Reopen on material new evidence. Complaint acknowledgement and final-response deadlines are not hardcoded here; the legal control register must define and monitor them per entity/jurisdiction. ## Escalation And SLA Control - Critical sanctions, suspected account takeover with funds at risk, ledger mismatch, or potential major incident: immediate paging and incident command. - AML/sanctions/fraud cases: SLA by risk and legal requirement, with daily overdue review and documented reassignment/escalation. - Regulatory filing and complaint deadlines: authoritative jurisdiction deadline, with reminders and management escalation before breach. - Provider dependency: record provider ticket/SLA and retain internal ownership; provider delay does not pause regulatory accountability unless law says so. ## Metrics, Assurance, And Evidence Compliance leadership reviews at least monthly: - KYC decision volume/time, manual-review/decline/override rates and provider errors - sanctions/PEP/adverse-media hits, false positives and ongoing-monitoring coverage - AML/fraud backlog, age, SLA breaches, escalation/report outcomes and tuning drift - EDD due/overdue decisions and periodic-review coverage - complaints volume, timeliness, upheld/remediation rate and recurring root causes - privileged access, exports, maker-checker exceptions and evidence completeness Retain evidence according to approved legal/privacy policies and legal holds. Export only necessary fields to approved immutable storage with checksum, access log, classification, retention date, and deletion authority. Internal audit or an independent control owner samples procedure execution and tracks remediation.