Monitor Execution Engine

Overview#

A financial institution runs thousands of transaction monitoring rules continuously. Some execute in near real-time to catch sanctions matches before settlement. Others run nightly batch sweeps across the full transaction history. A handful run hourly against specific high-risk account segments. The execution engine behind all of this cannot drop a monitoring window, cannot let one organisation's workload starve another's, and cannot silently fail in a way that leaves a compliance gap. When a regulator asks whether every required monitor ran on schedule for the past quarter, the answer must be verifiable, not estimated.

The Monitor Execution Engine provides reliable, scheduled, and on-demand execution for all configured monitors across globally distributed infrastructure. Multi-tenant isolation means one organisation's peak workload never affects another's, and data sovereignty rules ensure each monitor's data processing stays within its required jurisdiction.

Open Standards#

• Cron expression syntax (POSIX/Vixie cron): Monitor cadences are defined and persisted as five-field cron expressions; the croniter library evaluates them to compute exact next-run timestamps.
• ISO 8601: All execution timestamps (scheduled time, started_at, completed_at, next_run) are stored as timezone-aware datetimes and serialised to ISO 8601 strings via .isoformat() and fromisoformat().
• GraphQL (June 2018 specification): The entire Monitor domain API surface, including queries for listing and retrieving monitors and mutations for creation, update, and approval, is implemented as a typed GraphQL schema.
• JSON (RFC 8259): Monitor query configurations, alert configurations, threshold definitions, and execution statistics are stored as JSONB and exchanged as JSON throughout the API.
• IANA Time Zone Database: Time-zone-aware scheduling for multi-region execution uses UTC as the canonical baseline, with timezone-aware datetime columns mapping to IANA named zones for local-time scheduling in each region.
• Dead-letter queue pattern (AMQP-derived): Persistently failing executions are captured in a structured dead-letter queue with dedicated GraphQL operations for review, manual requeue, and archival.
• OAuth 2.0 (RFC 6749): Role-based access control gating monitor approval (admin and automation_approver roles) is enforced via bearer-token claims consistent with the platform-wide OAuth 2.0 authorisation model.
• GDPR (Regulation (EU) 2016/679): Data residency zones (EU_WEST, EU_NORTH, EU_SOUTH, EU_EAST) and strict data-sovereignty routing ensure that each monitor's data processing stays within its required jurisdiction in compliance with GDPR data localisation obligations.

Last Reviewed: 2026-02-05 Last Updated: 2026-04-14

Key Features#

Reliable Automated Execution#

• High-reliability execution with documented minimal missed monitoring windows
• Low-latency processing from scheduled time to result delivery across all monitor types
• Parallel execution capacity handles peak compliance workloads without degradation
• Multi-tenant isolation ensures one organisation's monitors never impact another's performance
• Elastic scaling responds to traffic changes automatically to maintain consistent performance

Flexible Scheduling#

• Configurable execution frequencies from real-time streaming to hourly, daily, or custom intervals
• On-demand execution for immediate manual runs during urgent investigations
• Time-zone-aware scheduling ensures monitors execute at appropriate local times for each region
• Priority-based scheduling ensures critical monitors receive preferred execution slots
• Maintenance windows allow planned pauses without losing monitoring coverage

Global Execution Reach#

• Regional execution zones placed for proximity to major data sources across North America, Europe, Asia-Pacific, Latin America, and the Middle East
• Data-locality-aware routing executes monitors near their data sources to minimise latency
• Automatic failover redirects execution to alternative regions when infrastructure issues arise
• Data sovereignty compliance ensures processing occurs within required jurisdictions for every monitor

Retry Logic and Fault Tolerance#

• Automatic retry with configurable policies for transient failures
• Exponential backoff prevents overwhelming recovering data sources during incident recovery
• Dead-letter handling captures persistently failing executions for manual review and operational alerting
• Partial result processing extracts value from executions that partially succeed

Result Management#

• Result caching eliminates redundant computation when multiple monitors query similar data
• Historical result storage enables trend analysis and performance comparison over time
• Execution metadata captures timing, data volumes, and outcomes for performance tracking

Use Cases#

Continuous Compliance Monitoring#

Financial institutions run thousands of monitors around the clock to meet regulatory obligations for transaction monitoring, sanctions screening, and suspicious activity detection. The execution engine ensures every monitor runs on schedule with documented reliability for regulatory examination.

Real-Time Threat Detection#

Security operations teams deploy monitors that execute in near real-time, enabling rapid detection and response to unauthorised access patterns, anomalous transaction flows, or sanctions list matches.

Multi-Jurisdiction Operations#

Organisations operating across multiple countries rely on region-specific execution to comply with data sovereignty requirements while maintaining centralised monitoring program management.

Peak Workload Management#

During end-of-day, end-of-month, or regulatory reporting periods, execution volumes spike significantly. The engine scales automatically to handle these peaks without manual intervention or performance degradation.

Integration#

• Monitor Configuration: Configured monitors are automatically registered for execution based on their defined schedules
• Alert System: Execution results meeting alert criteria are immediately routed to the alert management pipeline
• Analytics Platform: Execution metrics feed into performance analytics for continuous monitoring program optimisation
• Data Sources: The engine connects to blockchain nodes, transaction databases, sanctions lists, and other intelligence sources as required by each monitor's configuration