BCMS

Automated Compliance Monitoring Controls in Odoo SOP

6 min read

Purpose

Register the Automated Compliance Monitoring Controls in Odoo memorandum as the implementation SOP for Odoo SaaS automations that identify, route, evidence and report compliance events.

This SOP is subordinate to PROC-IT-008 Manage Technology Change Acquisition and Outsourced IT Services. It also implements IT service management, computer-risk and software-testing requirements and supports the linked AML, KYC, FIU-reporting, privacy and assurance procedures.

Source Document

  • Document title: Automated Compliance Monitoring Controls in Odoo
  • Document type: implementation memorandum
  • Date: 2026-04-25
  • Entity: Bitkaya B.V.
  • System: Odoo SaaS 19.1
  • Prepared by: Cees Quirijns
  • Recipient: Compliance Department
  • Approval shown in document: none
  • Permanent artifact: 20260425 Memo Automated Compliance Controls in Odoo.pdf
  • Artifact SHA-256: 2a943854c44b9ae55be6ba4f99efbc31ed6b0a1b40655725bd737034f67a0005

Architecture

SYS-IT-001 Odoo Automated Compliance Monitoring uses Odoo automations, scheduled actions, custom fields and Helpdesk tickets as the workflow and evidence mechanism.

  • Compliance Helpdesk, ID 2: alerts, customer-file reviews, scheduled reports and gap analyses.
  • Registers Helpdesk, ID 6: UTR/FIU register tickets and FIU-report records.
  • Customer Care Helpdesk: initial receipt of AMLBot wallet-risk messages before controlled routing.

Client followers must be removed from internal compliance and UTR/FIU tickets unless an approved workflow explicitly requires otherwise. Access to restricted AML, wallet-risk, suspicion and reporting information must be role-based and logged.

Automated Control Domains

Transaction Monitoring

Odoo creates Compliance Helpdesk tickets for qualifying Sales Orders and Purchase Orders involving:

  • individual transactions above the configured 30,000 XCG equivalent threshold;
  • cumulative transactions above 30,000 XCG within seven days for the same client;
  • confirmed transactions by clients classified as high risk; and
  • deviations from expected average trade size or annual trade count.

The same control logic must cover both Sales Orders and Purchase Orders, use controlled currency conversion and transaction status, prevent duplicates and preserve the source-order link.

UTR and FIU Workflow Support

For a qualifying order, Odoo creates an internal UTR/FIU ticket in the Registers Helpdesk containing the internal reference, transaction type and date, client identity and address information, original and XCG-converted amounts, configured threshold and source-order link.

Automatic ticket creation is an internal detection and workflow action. It does not determine whether a report is legally required, does not constitute submission to FIU Curacao and must not bypass documented MLRO or Compliance review under PROC-AML-005 Perform FIU Reporting and Case Escalation.

Customer File and KYC Monitoring

Odoo:

  • creates an ID-update reminder 14 days before expiry;
  • calculates the next risk-review date from risk-profile data;
  • creates a risk-review reminder 14 days before the due date;
  • marks KYC incomplete when the risk review expires; and
  • changes KYC/trading permission to No when an in-scope client ID expires and records an automated log note.

The current ID-expiry scope uses the Client tag, excludes the B2B tag and requires an ID-validity date. Compliance must separately confirm complete coverage for legal entities, beneficial owners, representatives and other persons whose documents or reviews expire.

AMLBot Wallet-Risk Routing

Odoo routes AMLBot tickets with the exact subject Address risk score was updated, extracts wallet addresses and compares them with configured SOL, ERC, BTC and TRC contact fields.

  • One match: assign the client, move the ticket to Compliance, classify it as Transaction Monitoring, post an internal note and remove the client follower.
  • No match: post an internal note requiring manual review.
  • Multiple matches: record possible matches for manual review without automatic client assignment.

The automation supports routing only. Compliance remains responsible for risk assessment, restrictive action, investigation, escalation and reporting decisions.

Scheduled Oversight Reports

The configured or prepared report set includes:

  • monthly ID Validity Report;
  • weekly, monthly, quarterly and yearly Transaction Monitoring Reports;
  • monthly, quarterly and yearly UTR Reports;
  • monthly AMLBot Gap Analysis; and
  • monthly and quarterly UTR Gap Analysis.

Each scheduled execution must produce a dated ticket even when no exceptions are found, identify its source population and period, and receive documented Compliance review and closure.

Gap Analysis

  • AMLBot Gap Analysis compares active-client SO/PO activity with AMLBot ticket evidence and identifies clients without wallet-screening evidence in the lookback period.
  • UTR Gap Analysis independently recalculates in-scope SO/PO values in XCG and identifies transactions above the configured threshold without a corresponding Registers Helpdesk ticket.

Gap analysis must be sufficiently independent from the triggering automation to detect common-mode failures in source selection, conversion, status logic, partner identification and duplicate flags.

Configuration Baseline

The controlled baseline includes the memo’s listed contact, SO/PO and Helpdesk custom fields, automation identifiers, scheduled actions, Helpdesk IDs, categories, ticket titles, follower rules, conversion method, duplicate-prevention flags and report frequencies.

Technology must retain an export or equivalent record of:

  • automation and scheduled-action code;
  • trigger model, domain, execution user and permissions;
  • custom field technical name, type and allowed values;
  • threshold, lookback, timezone and exchange-rate configuration;
  • Helpdesk, category, stage, assignment and follower configuration;
  • version, approval, deployment date and rollback method; and
  • dependencies on AMLBot email format, wallet fields, client tags and SO/PO workflow states.

Exception and Failure Handling

The following must create visible, assigned and time-bound exceptions:

  • unmatched or multiply matched wallet address;
  • missing AMLBot evidence;
  • missing UTR/FIU ticket;
  • automation or scheduled-action failure;
  • stale or unreviewed monitoring ticket;
  • missing, invalid or unavailable exchange rate;
  • duplicate or suppressed alert;
  • incomplete source population or report;
  • unauthorized configuration change;
  • accidental client follower or unauthorized disclosure; and
  • failed KYC restriction or reminder update.

Material failures must be assessed for client restriction, retrospective lookback, FIU or CBCS consequences, incident reporting and remediation.

Required Acceptance and Periodic Testing

Before this SOP moves from review to implemented or operational:

  1. Approve the control inventory, code/configuration baseline, owners, access roles and change workflow.
  2. Confirm the current legal indicator and XCG threshold, conversion source, timezone, order status and lookback logic.
  3. Test positive, negative, boundary, duplicate, cancellation, refund, currency, high-risk, profile-deviation and cumulative scenarios for SO and PO flows.
  4. Test exact, absent, malformed and changed AMLBot subject/body formats and zero, one and multiple wallet matches.
  5. Test ID and risk-review reminders, expiry restrictions, B2B/legal-entity coverage and restoration after approved remediation.
  6. Reconcile scheduled-report populations to independent source queries and test that no-finding reports are still generated.
  7. Confirm MLRO/Compliance decisioning, FIU submission and tipping-off safeguards are not automated away.
  8. Test role access, follower removal, chatter confidentiality, audit logs, backups, recovery, failure alerts and rollback.
  9. Retain screenshots, configuration exports, test scripts, expected and actual results, defects, approvals and remediation.
  10. Reperform representative tests after material code, field, policy, threshold, Odoo, AMLBot or workflow change and at least annually.

Evidence

  • Approved automation inventory and configuration baseline
  • Odoo code/configuration exports and change records
  • Access-role and internal-follower tests
  • SO/PO scenario and boundary test results
  • AMLBot routing and wallet-match test results
  • ID and risk-review reminder and restriction tests
  • Scheduled report execution and independent reconciliation
  • UTR and AMLBot gap-analysis exceptions and closure
  • Monitoring and UTR/FIU tickets with review evidence
  • Failure alerts, incidents, lookbacks and remediation
  • Annual control-owner review and independent assurance

Assurance

  • Document registered: yes
  • Artifact integrity captured: yes
  • Document approval: not evidenced
  • Automation code and configuration inspected by Codex: no
  • Production operation independently tested: no
  • Regulatory indicator and threshold verified against current authoritative instruction: no
  • Overall status: implementation memorandum registered for review; design approval and operating-effectiveness evidence remain pending under ISS-IT-001 Confirm Odoo Compliance Automation Security Testing and Operating Evidence

History

  • 2026-07-26: Registered the 25 April 2026 implementation memorandum as the Odoo compliance automation SOP under PROC-IT-008.

Graph View

Backlinks