Real-Time Compliance Pipelines: A Review of Automated Risk Monitoring and Enterprise Data Governance

Full text

Text extracted from the article PDF for reading and search. Tables, figures and equations are in the PDF, which remains the authoritative version.

1. Introduction

Compliance has historically been a retrospective discipline. Controls were designed to detect that something went wrong, produce evidence that the detection occurred, and demonstrate to an examiner that remediation followed. The temporal unit of that cycle was typically the day, the month, or the quarter. This design was coherent when the events under supervision were themselves slow, when a wire transfer took days to settle, when a trade was confirmed by paper, and when customer data lived in a small number of systems of record under a single operational owner (Aminu-Ibrahim et al., 2018).

Three concurrent shifts have destabilized this arrangement. Transaction velocity increased first. Real-time gross settlement systems, instant payment rails, and card-not-present commerce reduced the settlement window from days to seconds, so a detection control that fires twelve hours after the fact can no longer prevent loss and can only document it. In financial crime specifically, funds have typically left the institution and the jurisdiction before a batch alert reaches an analyst’s queue (Ogbete et al., 2018).

Data topology fragmented next. The consolidation of enterprise data into a single warehouse, which underpinned the classical control design, gave way to distributed estates: multiple clouds, object storage lakes, streaming platforms, operational microservice databases, and third-party software-as-a-service systems holding regulated data outside the enterprise perimeter. Governance controls that assumed a single chokepoint lost their chokepoint (Ogbete et al., 2021). Regulatory expectations then tightened around data itself rather than only around outcomes. The Basel Committee’s principles for effective risk data aggregation and risk reporting (BCBS 239) made data lineage, accuracy, completeness, and timeliness supervisory concerns in their own right. The General Data Protection Regulation made the ability to locate, restrict, and erase personal data an enforceable obligation with a short response clock. These regimes do not merely ask whether an institution reached the right answer; they ask whether it can demonstrate how the answer was assembled. The convergence of these pressures produced a design response: move compliance logic out of the periodic reporting layer and into the operational data path, so that assessment happens as events occur rather than after they have accumulated (Bello et al., 2022). We define a real-time compliance pipeline as a continuously running data processing system that ingests business events from operational sources with bounded, monitored latency; enriches those events with reference, historical, and contextual state; evaluates them against externally versioned representations of regulatory, policy, or risk logic; emits typed outputs such as alerts, blocks, holds, obligations, or attestations with sufficient provenance to reconstruct the decision; and preserves an immutable, queryable evidentiary record of the entire chain (Bello et al., 2022). The last of those properties is what distinguishes a compliance pipeline from a generic streaming analytics application. A recommendation engine may discard the inputs to a scoring decision once the recommendation is served. A compliance pipeline may not. The evidentiary requirement propagates backwards into every architectural choice, constraining storage, retention, schema evolution, and even the choice of processing semantics (Michael and Ogunsola, 2019a).

Throughout, automated risk monitoring refers to the detection layer, meaning the analytical methods that convert enriched event streams into risk signals, and enterprise data governance refers to the control plane, meaning the catalog, lineage, quality, policy, and access management functions that determine whether the data feeding those detections is trustworthy and lawfully used. These two layers are frequently studied and procured separately, and that separation is a recurring source of failure in deployed systems (Michael and Ogunsola, 2021b).

The review draws on a corpus of 204 works published between 2015 and 2022, spanning compliance and risk analytics, data governance and enterprise information systems, cybersecurity and operational technology, and a set of adjacent regulated-sector studies retained because they evidence the generality of the control and assurance patterns under examination. Work published after December 2022 is outside scope, as is purely batch regulatory reporting with no continuous component and general-purpose anomaly detection with no compliance framing. Primary legislative instruments, supervisory guidance, and technical standards are identified in the text by name and issuing body rather than enumerated in the reference list, since they are normative sources rather than research contributions. Where implementation experience is drawn from practitioner rather than peer-reviewed sources, it is used to establish that a pattern occurs and is implementable at stated scale, never to establish comparative effectiveness, since reported outcomes there are self-selected and negative results are almost never published (Michael and Ogunsola, 2021e). The discussion proceeds from background and regulatory drivers through architecture, detection technique, governance integration, and evaluation, and closes with the problems that remain unresolved at the end of the period examined.

2. Background and Definitions

2.1. From Periodic Controls to Continuous Controls

Monitoring The concept of continuous controls monitoring (CCM) predates streaming infrastructure. Internal audit literature from the early 2000s onward proposed automated, high-frequency testing of control effectiveness as an alternative to sample-based annual testing. Early CCM implementations were, in practice, scheduled batch queries running against enterprise resource planning extracts at daily or weekly intervals. The conceptual framing was continuous; the implementation was not (Akomolafe and Agu, 2018; Dogbatsey and Ebhojie, 2018).

What changed after roughly 2015 was the commoditization of durable, replayable, horizontally scalable log infrastructure. Once an ordered, retained event log became a standard piece of enterprise infrastructure rather than a bespoke engineering project, the gap between the CCM concept and its implementation narrowed substantially. The log provided three properties that compliance work specifically requires: durability (evidence is not lost), ordering (sequence can be reconstructed), and replay (a control can be re-executed against historical data under revised logic) (Akomolafe and Agu, 2019b; Dogbatsey et al., 2021).

2.2. Stream Processing Foundations

Three semantic concepts from the stream processing literature bear directly on compliance correctness and are worth stating explicitly, because compliance requirements interact with them in non-obvious ways (Amayo et al., 2015; Amayo, 2017; Amayo and Popoola, 2017b).

Event Time Versus Processing Time: An event carries the timestamp at which it occurred in the business domain; the pipeline also observes the time at which it arrived. Regulatory obligations are almost always expressed in event time. A rule stating that aggregate transfers exceeding a threshold within a rolling twenty-four hour period must be reported refers to the customer’s twenty-four hours, not the pipeline’s. Systems that window on processing time will silently produce incorrect regulatory determinations whenever ingestion is delayed, and the error will be invisible in normal operation and appear precisely during incidents, when ingestion delay is most likely (Dagodzo and Ahiaeke Patrick, 2020; Oshevire Watermarks and Lateness: Because distributed sources deliver out of order, streaming engines use watermarks to estimate completeness and decide when a window may be closed. Compliance introduces an unusual constraint: dropping late data is generally not an acceptable default. A late-arriving transaction that would have completed a structuring pattern cannot simply be discarded because a watermark advanced. Compliance pipelines therefore need explicit allowed-lateness policies, side outputs for late records, and a defined remediation path that produces a retroactive alert rather than silence.

Delivery Semantics: At-least-once delivery, the pragmatic default in many streaming systems, produces duplicates. In a compliance context duplicates are not merely noise; a duplicated transaction can push a customer over an aggregate reporting threshold, generating a false regulatory filing, or a duplicated alert can inflate case volumes and distort effectiveness metrics reported to supervisors. Effectively-once processing, achieved through transactional writes and idempotent sinks, is a functional requirement rather than an optimization in this domain.

2.3. Data Governance as an Operational Function

Classical data governance literature frames governance as an organizational construct: decision rights, accountability, stewardship, and policy. Practical implementations, however, were long dominated by documentation artifacts, meaning spreadsheets of critical data elements, manually maintained lineage diagrams, and periodic data quality scorecards (Borah et al., 2022; Mbonu et al., 2020b).

The relevant evolution is the shift from governance as documentation to governance as executable infrastructure. Under this framing, a data classification is not a label in a registry but a machine-readable attribute that an access control engine consults at query time. Lineage is not a diagram but a graph emitted automatically by processing jobs and queried programmatically to answer impact questions. A retention policy is not a written standard but a scheduled operation with a verifiable outcome. This shift is what makes governance capable of participating in a real-time pipeline rather than describing it after the fact (Mbonu et al., 2019; Mbonu et al., 2021b).

2.4. Terminological Clarification

The reviewed literature uses several overlapping terms inconsistently. We adopt the following distinctions for this paper:

Table 1 Term Usage in this paper Preventive control Executes before the business event completes and can block it Detective control Executes after completion and produces an alert or finding Real-time Bounded latency measured in milliseconds to seconds, in the event path Near-real-time Bounded latency measured in seconds to minutes, typically micro-batch Continuous High-frequency but not necessarily event-triggered; includes scheduled minute-level execution Observability Instrumentation of the pipeline itself, distinct from the compliance monitoring it performs The distinction between preventive and detective placement is the most consequential architectural decision in the domain, and Section 4 treats it in detail (Badmus et al., 2019a; Badmus et al., 2019b; Badmus et al., 2022a).

2.5. Adjacent Streams of Work

Real-time compliance sits at the intersection of several research and practice traditions that developed independently, and the terminology of each obscures how much they share. Locating the topic against those traditions clarifies which problems are genuinely open and which have been solved under another name (Borah et al., 2022; Mbonu et al., 2018; Mbonu et al., 2020).

The continuous auditing tradition, originating in internal audit and accounting information systems research, established the argument that control testing should move from periodic sampling to population-level automated evaluation. Its conceptual apparatus, including the distinction between control monitoring and transaction monitoring and the notion of an audit layer that operates independently of the systems it observes, transfers directly to the compliance setting. What that tradition lacked, until streaming infrastructure matured, was an implementation substrate capable of population-level evaluation at operational speed, which is why its early implementations reduced in practice to frequent batch queries (Badmus et al., 2020; Ladapo et al., 2018).

The regulatory technology literature approaches the same problem from the obligation side, asking how regulatory requirements can be represented, automated, and reported against, and extending to the supervisory perspective in which authorities themselves consume machine-readable submissions. This literature is strong on the institutional and legal dimensions and comparatively thin on the engineering constraints that determine whether a proposed automation is achievable at production volume and latency (Atakpa and Abolaji, 2022; Atakpa and Abetoh, 2022). Data quality and master data management research contributes the measurement apparatus that governance requires. Dimensional models of quality, covering accuracy, completeness, consistency, timeliness, and validity, are directly reusable as the assertion vocabulary of an inline validation stage. The gap is that this literature has typically assumed batch profiling against a settled dataset rather than continuous assertion against an unbounded stream, where the reference population against which an anomaly is judged is itself moving (Mbonu et al., 2021a; Mbonu et al., 2021b). Event-driven architecture and distributed systems research supplies the execution model, including the ordering, delivery, and state management semantics discussed in Section 2.2. This literature rarely addresses evidentiary requirements, because its motivating applications, such as recommendation, personalization, and operational alerting, do not need to reconstruct a decision years later. Security operations research contributes the closest operational analogue. A security information and event management deployment ingests heterogeneous telemetry, applies correlation rules and behavioral analytics, generates alerts into an analyst queue, and struggles with false positive volume and analyst capacity in precisely the manner described in Section 6.7. The parallels extend to the organizational pattern, in which detection engineering and investigation are separate functions with different incentives. Where the two diverge is in evidentiary burden and in the consequences of error, since a suppressed security alert is an operational risk while a suppressed compliance alert can become a supervisory finding or a personal liability for a named officer.

The reason these traditions have not converged is partly institutional. They publish in different venues, are procured through different budgets, and are staffed by people with different professional qualifications. An institution’s continuous auditing capability typically reports to internal audit, its transaction monitoring to financial crime compliance, its data quality programme to a chief data officer, and its streaming platform to engineering. The technical convergence described in this review therefore requires an organizational convergence that Section 9.7 argues is the harder of the two.

3. The Regulatory and Standards Landscape

Real-time compliance pipelines are not motivated by a single regulation but by the cumulative structure of several regimes, each contributing a distinct architectural requirement. This section organizes the drivers by the requirement they impose rather than by jurisdiction.

3.1. Timeliness Requirements

Payments and Financial Crime: Anti-money laundering regimes impose both detection and reporting obligations. Sanctions screening is the clearest preventive case: screening against consolidated sanctions lists must occur before funds are released, which places the control synchronously in the payment path with a hard latency budget. Transaction monitoring for suspicious patterns is traditionally detective, but the shrinking settlement window has pushed institutions toward in-flight scoring with hold capability for the highest-risk segment (Adebayo et al., 2022; Adeyelu, 2019; Dada et al., 2021b).

Market Conduct: Market abuse and best execution regimes require surveillance across order lifecycle events at a granularity and volume that makes end-of-day batch processing increasingly impractical, particularly where cross-venue and cross-asset correlation is required to detect layering, spoofing, or wash trading patterns (Adegbite et al., 2022; Adeyelu, 2021; Isiekwu et al., 2021). Operational Resilience: Supervisory attention to operational and information and communication technology risk, culminating in the European digital operational resilience framework proposed in this period, extended timeliness expectations from financial data to incident detection and reporting itself, with short mandated notification windows for major incidents (Adeyelu and Dagodzo, 2022; Dada et al., 2021a).

3.2. Data Quality, Aggregation, and Lineage

Requirements BCBS 239 remains the most explicit statement that data infrastructure is itself a supervisory object. Its principles require accuracy and integrity, completeness, timeliness, and adaptability in risk data aggregation, and they require that institutions be able to explain how aggregated risk figures were derived. Operationally this means that lineage cannot be a documentation exercise; it must be derivable from the systems that actually transform the data. Supervisory reviews in the decade following its issuance repeatedly identified aggregation capability and data architecture as areas of persistent weakness across large institutions, which is itself evidence that documentation-based approaches did not satisfy the requirement (Dogbatsey et al., 2019).

3.3. Privacy and Data Subject Rights

The GDPR and comparable regimes, including the California Consumer Privacy Act as amended by the CPRA, impose obligations whose fulfillment depends on capabilities that are architecturally identical to governance capabilities: knowing what personal data exists, where it resides, on what lawful basis it is processed, who may access it, and how to locate every copy for restriction or erasure within a defined response period (Atima et al., 2022; Ekechi et al., 2022; Sanni et al., 2020b).

These regimes create a structural tension with monitoring obligations that this review treats as a first-class problem rather than an implementation detail. Data minimization pulls toward collecting and retaining less; surveillance obligations pull toward retaining more, for longer, in linkable form. Purpose limitation restricts reuse of data collected for one purpose in a different analytical context, yet effective risk detection frequently depends on exactly such cross-context correlation. Section 9.6 develops this tension (Ozowara et al., 2022; Sanni and Atima, 2021b; Sanni et al., 2022).

3.4. Emerging Algorithmic Accountability

The European Commission’s proposed artificial intelligence regulation, published in 2021, signaled the extension of supervisory attention to the detection models themselves, with requirements around risk management, data governance for training data, technical documentation, logging, human oversight, and accuracy. Existing model risk management supervisory guidance in banking already imposed development, validation, and governance expectations on models used in risk decisions. The direction of travel is that a machine learning model used to make or materially influence a compliance decision is subject to a documentation and validation burden comparable to the decision itself, which constrains model selection in ways discussed in Section 6 (Annan, 2022; Eze et al., 2022a).

3.5 Summary Mapping

Table 2 Regulatory driver Primary architectural requirement Affected pipeline layer Sanctions screening Synchronous, sub-second, preventive placement Ingestion, decision Transaction monitoring Stateful aggregation over event-time windows Enrichment, detection Market surveillance Cross-source correlation, sequence detection Enrichment, detection BCBS 239 Automated lineage, quality instrumentation, reconciliation Governance plane, evidence GDPR / CPRA Classification, purpose binding, erasure propagation Governance plane, storage Operational resilience Pipeline self-observability, incident detection Observability Model risk and AI governance Model versioning, explainability, decision logging Detection, evidence

3.6. Obligations Beyond Financial Services

The financial sector supplies the densest concentration of real-time compliance obligations, but the underlying pattern, in which a regulated activity generates events that must be assessed against rules within a bounded time and evidenced afterwards, recurs across sectors. Reviewing those adjacent regimes matters for two reasons: it tests whether the architecture in Section 4 is genuinely general or merely a financial services artifact, and it identifies obligation types that financial services does not exercise (Boakye et al., 2021; Ilodigwe and Adesemoye, 2019a; Komi and Adamolekun, 2021; Ogbete et al., 2019).

Healthcare imposes obligations on both clinical and administrative data. Privacy and security rules govern access to patient records, with audit logging of access as an explicit control rather than an optional practice, which makes the access log an evidentiary artifact of the same kind as a compliance decision record. Infrastructure and diagnostic capacity planning introduces a second obligation class concerned with service availability and equitable access, which is monitored through operational reporting rather than transactional screening. The distinguishing feature relative to finance is that the consequence of a delayed detection is clinical rather than financial, which changes the acceptable trade-off between precision and speed (Ilodigwe and Adesemoye, 2020; Komi and Adeniji, 2020; Lilian et al., 2020; Ogbete et al., 2022).

Pharmaceutical regulation contributes obligation types with no close financial analogue. Good practice requirements for manufacturing and distribution place evidentiary demands on process data, including the expectation that records be attributable, legible, contemporaneous, original, and accurate, which is an evidentiary standard articulated more explicitly than most financial regimes manage. Serialization and traceability requirements for medicinal products impose an event-level chain of custody across organizational boundaries, which is structurally the same problem as cross-institutional transaction tracing and faces the same barrier of commercially sensitive data sharing. Pharmacovigilance imposes reporting clocks on adverse event signals that are directly comparable to suspicious activity reporting deadlines (Asiedu and Asiedu, 2022; Komi, 2021; Michael and Ogunsola, 2019b; Ogbona et al., 2020b).

Aviation safety oversight operates a mature model of continuous regulatory assurance built on mandatory occurrence reporting, safety management systems, and continuing airworthiness monitoring. Two features are notable. First, the regime deliberately protects reporting from punitive use in order to sustain reporting volume, an explicit acknowledgment that detection depends on the willingness of humans to report and that enforcement posture affects detection coverage. Second, oversight is risk-based, with inspection intensity varying by assessed operator risk, which is the supervisory analogue of the capacity-constrained detection allocation problem described in Section 6.7 (Adeyelu, 2018; Asiedu, 2022; Michael and Ogunsola, 2021c; Yeboah and Oloto, 2022).

Energy and utility regulation combines critical infrastructure protection standards, which impose asset inventory, access control, and change monitoring obligations on operational technology environments, with environmental discharge and emissions monitoring that is genuinely continuous and sensor-driven. The operational technology setting is instructive because it inverts a common assumption: in that environment, availability and safety constraints frequently prohibit the intrusive instrumentation that compliance monitoring would prefer, so the monitoring architecture must be passive and out-of-band. Compliance pipelines in financial services rarely face a constraint of that severity, and designs that assume unrestricted instrumentation do not transfer (Adeyelu, 2020; Aye and Tawose, 2015; Michael and Ogunsola, 2022a; Yeboah et al., 2022).

Public sector accounting and procurement contribute obligations around transparency, competitive process, and expenditure control, where the evidentiary requirement attaches to the decision process itself rather than to a transaction. Education and social services contribute obligations concerning the handling of data about minors and vulnerable individuals, where consent is complicated and the retention question is sharper than in commercial settings (Adeyelu, 2022; Aye and Tawose, 2016; Eze et al., 2022b; Okwah, 2022).

Two conclusions follow. First, the layered structure described in Section 4 is not sector-specific, since every one of these regimes requires capture, contextualization, rule evaluation, action, and evidence. Second, the parameters differ substantially, particularly the latency budget, the acceptable false positive rate, and the degree to which instrumentation may intrude on the monitored system, so a design transferred across sectors without recalibrating those parameters will fail even though its structure is sound (Aminu-Ibrahim et al., 2019; Ekeocha et al., 2021; Falegan and Aniebonam, 2022).

3.7. Standards, Control Frameworks, and Their

Relationship to Regulation Alongside binding regulation sits a layer of voluntary and quasi-mandatory frameworks that shape how institutions structure controls, and the relationship between the two layers is frequently misunderstood in implementation (Mbonu et al., 2019; Mbonu et al., 2020a; Mbonu et al., 2022). Information security management standards define control objectives and require a documented management system with defined scope, risk assessment, and continual improvement. Control catalogues issued by national standards bodies enumerate specific technical and organizational controls with implementation guidance.

Enterprise risk and internal control frameworks define the governance structure within which controls operate, distinguishing control environment, risk assessment, control activities, information and communication, and monitoring. Service management frameworks define the operational disciplines, particularly change, incident, and problem management, through which controls are maintained (Akomolafe and Agu, 2018; Atakpa, 2021). These frameworks are not regulation, and conflating them produces two errors in opposite directions. The first is treating certification against a standard as evidence of regulatory compliance, which it is not, since a management system can be certified while a specific obligation goes unmet. The second is dismissing the frameworks as unrelated overhead, which misses that supervisors frequently use them as the reference point for what constitutes reasonable practice, so departures from them require explanation even where they are not mandated (Mbonu et al., 2020b; Mbonu For real-time compliance pipelines specifically, the frameworks contribute three things. They supply a control vocabulary that maps the pipeline’s components to recognized control types, which materially eases supervisory explanation. They impose change management discipline on the artifacts described in Section 4.3, so a rule modification becomes a change record with approval, testing evidence, and rollback provision rather than an engineering deployment. And they supply the incident management structure through which a pipeline failure becomes a recorded, escalated, and reviewed event rather than an operational inconvenience, which matters because a period of control outage is precisely the sort of fact a supervisor expects to be recorded contemporaneously rather than reconstructed later. The practical difficulty is that these frameworks were written for systems that change on a release cycle, while streaming pipelines change continuously and their behavior depends on data as well as code. A change management process that requires approval for a code deployment but is silent on a threshold adjustment, a reference list update, or an automated model refresh leaves the most consequential changes ungoverned. Extending the change control boundary to cover configuration, reference data, and model artifacts is a routine recommendation in the reviewed material and a routine gap in practice.

4. Architecture of Real-Time Compliance Pipelines

Recurring structures across the reviewed implementations resolve into a seven-layer architecture. The layering is logical rather than physical; production systems collapse or distribute layers according to latency budget and organizational structure. We describe each layer by its function, its failure modes, and its interaction with the governance plane.

4.1. Layer 1: Event Capture and Ingestion

The ingestion layer converts state changes in operational systems into an ordered, durable event stream. Three capture patterns dominate (Agbabiaka et al., 2019; Amayo and Popoola, 2017a; Dagodzo, 2018a).

Application-emitted events produce the highest semantic quality, because the emitting service knows the business meaning of the change, but they require modification of source applications and are therefore unavailable for legacy and vendor systems (Ahiaeke Patrick et al., 2021; Amayo, 2017; Dagodzo et al., 2022).

Change data capture from database transaction logs requires no application modification and captures every committed change, but it delivers row-level physical changes that must be reassembled into business meaning downstream. A single business event may appear as writes across several tables, and reconstructing the business event from the physical changes introduces a semantic mapping that must itself be governed and versioned (Okonkwo et al., 2020; Oshevire et al., 2017). Periodic extraction remains common for third-party and legacy sources and represents the primary source of hybrid architectures, where part of the estate is streaming and part is not. Hybrid ingestion is not a transitional state to be designed away; in most large enterprises it is the permanent condition, and the architecture must accommodate mixed-freshness inputs explicitly rather than pretending to uniform freshness (Dagodzo and Ahiaeke Patrick, 2020; Okonkwo et al., 2018a).

The critical governance interaction at this layer is schema contract enforcement. A schema registry that rejects incompatible producer changes converts a class of silent downstream failures into a loud upstream one. Without it, a producer field rename can cause a compliance rule to evaluate a null value as a non-match, producing under-detection that is invisible because nothing errors (Dagodzo and Ahiaeke Patrick, 2021b; Okonkwo et al., 2021).

4.2. Layer 2: Enrichment and Contextualization

Raw events rarely contain enough context for a compliance determination. A transfer event carries amounts and account identifiers; the determination requires customer risk rating, beneficial ownership, jurisdiction exposure, historical behavioral baselines, and relationship context (Dagodzo and Ahiaeke Patrick, 2021a; Dagodzo and Ahiaeke Patrick, 2021b; Dagodzo and Ahiaeke Patrick, 2022). Enrichment introduces the architecture’s most persistent correctness hazard: temporal consistency of reference data. If an event from time T is enriched with a customer risk rating as of the current wall clock, the resulting decision is not reproducible, because re-running the same event later will use a different rating. Evidentiary reconstruction then fails: the institution cannot explain why the original decision was made. Correct designs bind enrichment to the reference state as of event time, which requires bitemporal reference stores that record both the business validity period and the system knowledge period of every attribute. This requirement is frequently discovered only when an examiner asks why a replayed case produces a different outcome than the original (Anene and Clement, 2022; Sanni et al., 2022). Feature stores, which emerged during this period as infrastructure for serving consistent features to training and inference, address a closely related consistency problem and are increasingly the mechanism through which this requirement is met (Dagodzo, 2018a; Dagodzo, 2018b).

4.3. Layer 3: Policy and Rule Representation

This layer holds the executable representation of regulatory and policy logic. The central design principle recurring across the corpus is externalization: compliance logic must live outside application code, in a versioned, independently deployable, independently testable artifact (Aifuwa et al., 2020; Badmus et al., 2022b; Filani et al., 2022). The motivations are specific to the domain rather than general software hygiene. First, change velocity is set by regulators, not by product roadmaps, and a rule change should not require an application release cycle. Second, the authors of the logic are compliance subject matter experts, not engineers, and the representation must be reviewable by them. Third, and most importantly, examiners ask which version of a rule was in force on a given date and require evidence that the deployed logic matched the approved logic. Compliance logic embedded in application source code makes that question expensive to answer; compliance logic in a versioned policy repository makes it a query (Ike et al., 2021; Ike et al., 2022).

Policy-as-code engines that evaluate declarative policy documents against structured input, with the policy artifact versioned in source control and independently unit tested, provide the mechanism. Decision tables and domain-specific rule languages serve the same function for tabular threshold logic and are often more accessible to non-engineering authors.

4.4. Layer 4: Detection and Scoring

The analytical core, treated in detail in Section 6. Architecturally, the significant property is that detection should be composable and independently versioned, with each detector declaring its inputs, its latency class, and its evidence requirements as metadata rather than as implicit properties of its code (Basnet et al., 2021; Tonoyan et al., 2021a; Tonoyan et al., 2021b).

A pattern recurring in mature implementations is the separation of signal generation from disposition. Individual detectors emit typed signals with confidence and context; a downstream disposition stage aggregates signals per entity, applies suppression and correlation logic, and decides what becomes a case. This separation permits detector logic to change without changing alerting thresholds, allows signals to be retained for tuning even when suppressed, and provides a natural place to address alert volume without weakening detection coverage (Tonoyan et al., 2022a; Tonoyan et al., 2022b).

4.5. Layer 5: Decision, Action, and Case Management

Outputs must be typed by the action they authorize, and the type determines the required latency and the required confidence. A synchronous block carries a customer impact cost and demands high precision within a hard latency budget. An asynchronous case for human review tolerates lower precision and looser latency. A watchlist addition or a risk-score adjustment carries lower immediate impact still (Lawal and Oduleye, 2018a; Medon and Oduleye, 2022). The latency budget allocation problem is under-treated in the literature relative to its practical importance. A synchronous control operating inside a payment authorization path may have a total budget of tens to low hundreds of milliseconds, from which enrichment lookups, policy evaluation, model inference, and evidence writes must all be served. This budget, not analytical sophistication, is the binding constraint on preventive placement, and it explains why sanctions screening is preventive while behavioral transaction monitoring generally is not (Lawal and Oduleye, 2019a). Case management closes the loop to human investigators, and its outputs, meaning investigator dispositions, are the primary supervised label source for improving detection. Pipelines that do not structurally capture disposition outcomes forfeit their ability to measure and improve precision (Lawal and Oduleye, 2021a).

4.6. Layer 6: Evidence and Audit Ledger

The evidence layer is the property that most distinguishes this architecture from general streaming analytics. For each material decision it must persist, in tamper-evident form: the input event, the enrichment values actually used with their temporal binding, the identity and version of every rule and model that executed, intermediate scores, the final decision, the actor or system that took it, and the timestamp of each step (Akomolafe et al., 2022).

The retention horizon is set by regulatory statute and by limitation periods, frequently five to ten years, which is considerably longer than typical streaming platform retention and typically longer than the operational lifetime of the pipeline components themselves. This creates a format longevity requirement: evidence must be readable by systems that do not yet exist, which argues against binary formats coupled to specific engine versions and in favor of open, self-describing formats with embedded schema. Tamper evidence is commonly implemented through append-only storage with write-once-read-many enforcement and cryptographic chaining of record hashes. Distributed ledger implementations appear in the literature of this period for cross-organizational evidence sharing, though the reviewed corpus provides limited evidence of production adoption for intra-enterprise compliance evidence, where simpler immutable object storage with object lock generally satisfies the requirement at lower operational cost.

4.7. Layer 7: Observability and Control Assurance

The pipeline is itself a control, and a control that fails silently is worse than an absent control, because it produces unwarranted assurance. This layer monitors the monitoring: ingestion lag by source, watermark progress, detector execution counts against expected baselines, null and default rates in enrichment fields, alert volumes against historical distributions, and end-to-end synthetic transaction tests that inject known-positive cases and verify detection (Adegbite et al., 2020; Dosunmu and Ogundele, 2019; Edivri and Oteri, 2022).

Synthetic positive injection deserves emphasis as an underused technique. It is the only method that verifies the entire chain end to end continuously, and it converts the question “is the control working?” from an annual testing exercise into a continuous measurement (Ahmed et al., 2021; Dosunmu and Ogundele, 2021; Okoruwa et al., 2020).

4.8. Deployment Topologies and Characteristic Failure

Modes The seven layers can be arranged in several topologies, and the choice determines both the control type achievable and the failure modes the system will exhibit (Ladapo et al., 2019; Ladapo et al., 2022).

Inline synchronous placement puts the pipeline in the request path, so the business transaction blocks pending a decision. This is the only topology that supports true prevention, and it is used where the obligation is absolute and the evaluation is cheap, most commonly sanctions screening. Its costs are severe: the compliance system becomes a availability dependency of the business system, its latency budget is bounded by customer-facing service level commitments, and its failure mode must be explicitly chosen between fail-open, which permits unscreened transactions, and fail-closed, which halts business. Neither is comfortable, and the choice is a policy decision rather than a technical one, which means it should be documented and approved rather than defaulted by an engineering team (Borah et al., 2022; Mbonu et al., 2018).

Asynchronous side-path placement consumes events from a log without blocking the transaction. It supports detection with lead times measured in seconds, imposes no availability dependency, and permits analytical depth that the synchronous budget forbids. It cannot prevent. Most behavioral monitoring occupies this topology (Adebayo et al., 2022; Adegbite et al., 2020).

Dual-path shadow placement runs a new detector alongside an incumbent, comparing outputs without acting on the new one. This is the principal safe mechanism for changing detection logic in a regulated setting, since it produces a documented comparison of coverage before and after, which is exactly the evidence a model or rule change approval requires. Its cost is doubled computation and the discipline required to actually retire the incumbent rather than accumulating both (Edivri and Oteri, 2022; Ogbole et al., 2021).

Tiered placement combines a cheap synchronous screen with a deeper asynchronous evaluation, allowing a fast partial decision followed by a considered one. It is the common resolution of the latency budget problem described in Section 4.5, and its characteristic hazard is inconsistency between the two tiers, where the synchronous tier clears a transaction that the asynchronous tier subsequently flags, requiring a defined reconciliation and remediation path.

Across topologies, a recurring set of failure modes appears in the corpus with enough consistency to be treated as characteristic rather than incidental.

Table 3 Failure mode Typical symptom Mitigation Silent under-detection Alert volume falls without an explanatory change Baseline alert rates per detector; alert on absence Enrichment default substitution Rules evaluate against null or default values Assert on null and default rates inline Key skew A small number of partitions saturate Composite keys; monitor per-partition lag Poison message Repeated task restart, consumer stall Dead-letter routing with mandatory review queue Backpressure collapse Growing lag under load spike Load shedding by risk tier, never uniformly State loss on upgrade Behavioral baselines reset Savepoint-based upgrade; state schema evolution Duplicate emission Inflated aggregates, duplicate filings Idempotent sinks, transactional writes Watermark stall Windows never close, no alerts emitted Idle source detection; watermark progress monitoring The first entry deserves emphasis because it is the most dangerous and the least likely to be noticed. Every other failure in the table announces itself through an error, a lag metric, or a restart. Silent under-detection produces a system that appears healthy, consumes its inputs, emits no errors, and simply stops finding things. Only an expectation of what the detector should produce, expressed as a monitored baseline, converts it into a visible fault, which is why the assurance instrumentation described in Section 4.7 is a functional requirement rather than operational hygiene. Load shedding warrants a similar note. When a pipeline cannot keep pace, the engineering instinct is to shed uniformly or to sample. In a compliance context uniform shedding is a decision to stop applying a regulatory control to a random subset of customers, which is difficult to defend and, in some regimes, is itself a reportable control failure. Shedding by risk tier, where lower-risk segments degrade to delayed evaluation while higher-risk segments retain real-time treatment, is defensible provided the tiering is documented and the delayed evaluation actually occurs.

4.9. Reference Data, Lists, and Their Management

Several layers of the architecture depend on reference data whose management is treated as an operational afterthought and which, in practice, is a frequent source of control failure (Dagodzo and Ahiaeke Patrick, 2020; Dagodzo and Ahiaeke Patrick, 2021a; Oshevire et al., 2017).

Sanctions and watchlist data illustrates the general case. Lists are published by multiple authorities on independent schedules, in inconsistent formats, with varying conventions for names, aliases, dates of birth, and identifiers. An institution must consolidate them into a screening reference, apply its own additions and internal lists, and distribute the result to every screening point. Each step introduces the possibility of divergence, and the consequence of divergence is that two screening points reach different conclusions about the same party, which is both a control failure and an explanation problem (Badmus et al., 2022a; Badmus et al., 2022b).

Three properties determine whether list management is defensible. The first is freshness, meaning the interval between publication of a list change and its effectiveness at every screening point, which should be measured and reported rather than assumed. The second is versioning, meaning that every screening decision records which list version it was evaluated against, without which a historical decision cannot be explained. The third is completeness of distribution, meaning verified confirmation that every screening point received and applied the update, since partial distribution produces the divergence described above and is invisible unless explicitly checked (Lawal and Oduleye, 2021b; Medon and Oduleye, 2022).

Beyond lists, the enrichment layer depends on customer reference data, product and account reference data, jurisdiction and geography mappings, and organizational hierarchy data. Each carries the bitemporal requirement discussed in Section 4.2, and each typically originates in a system whose owners have no visibility into the compliance dependency. A field that a source system treats as descriptive may be load-bearing for a compliance rule, and its owners will alter it without consultation because nothing signals the dependency. The lineage capability described in Section 7.4 is the mechanism that makes such dependencies visible, and the reference data domain is where its absence is felt most sharply (Dagodzo and Ahiaeke Patrick, 2021b; Dagodzo and Ahiaeke Patrick, 2022).

Reference data quality also determines the ceiling on detection quality in a way that additional analytics cannot overcome. If jurisdiction is recorded inconsistently, geographic risk rules will misfire regardless of their sophistication. If beneficial ownership is stale, ownership-based typologies will not detect what they are designed to detect. Investment in reference data is therefore frequently the highest-yield improvement available to a monitoring programme, and it is consistently less attractive to sponsors than investment in detection technique because its benefits are diffuse and its outputs are not demonstrable.

4.10. Time Semantics in Practice

The distinction between event time and processing time introduced in Section 2.2 has consequences at every layer, and working through them concretely clarifies why compliance pipelines cannot adopt streaming defaults unmodified (Ladapo et al., 2019; Ladapo et al., 2022). Consider an aggregate threshold obligation, in which cumulative transfers by a party above a stated amount within a rolling period must be reported. The period is defined in the customer’s time, so the window must be an event-time window. If ingestion from one source is delayed by an hour, a processing-time window will close before the delayed events arrive, compute a total below the threshold, and produce no report. Nothing fails, no error is raised, and the omission is discoverable only through reconciliation against source volumes. This is the mechanism behind a substantial share of the reporting failures that supervisors identify retrospectively (Anene and Clement, 2022; Basnet et al., 2021).

Event-time windowing avoids that outcome but requires a completeness estimate, which watermarks provide by asserting that events earlier than a given timestamp are not expected. Watermark generation is a heuristic, and in a heterogeneous estate the heuristic must accommodate the slowest source, which delays every window close to the pace of the least timely input. The alternative, generating watermarks per source and combining them, produces earlier closes at the cost of more late data. Neither choice is free, and the choice should be made against the reporting deadline rather than against throughput (Mbonu et al., 2022a; Mbonu et al., 2022b).

Late data then requires an explicit policy. Discarding it is the streaming default and is not defensible where the discarded event would have changed a regulatory determination. Allowing indefinite lateness is not implementable, since state cannot be retained without bound. The workable arrangement is a defined allowed-lateness period during which windows are updated and retractions or supplementary alerts are emitted, followed by routing of anything later to a side output that feeds a manual remediation process. The critical design property is that the pipeline emits a retroactive determination rather than silence, and that the retroactive determination is distinguishable in the evidence record from an original one, for the reasons discussed in Section 9.2 (Edivri and Oteri, 2022; Ogbole et al., 2021).

Retroactive determinations create a downstream obligation that is frequently unplanned. If an aggregate threshold is crossed only after late data arrives, the reporting clock may have started at the moment the threshold was actually crossed in event time rather than at the moment the pipeline observed it. Whether that is so is a legal question that varies by regime, and it should be answered before the situation arises rather than during it, because the answer determines whether late arrival creates a mere data quality issue or a missed deadline. Timestamp quality underlies all of this and is rarely examined. Source systems record times in local zones, in inconsistent formats, sometimes with the time of writing rather than the time of occurrence, and occasionally with clock skew across nodes. A pipeline that treats the timestamp field as authoritative without validating it inherits every one of those defects into its window boundaries. Assertions on timestamp plausibility, including future-dated events, implausibly old events, and distribution shifts in the lag between event time and arrival time, belong in the inline validation stage described in Section 7.3 rather than in a periodic data quality report.

A final consideration concerns rules that reference wall-clock deadlines, such as obligations expressed in business days from a triggering event. These require a calendar, and calendars are jurisdiction-specific, change annually, and are frequently maintained in a spreadsheet outside any governed system. A deadline computation that depends on an ungoverned calendar is an ungoverned control, and the calendar deserves the same versioning and distribution discipline as the reference data discussed in Section 4.9. A related consideration is that the same event may be subject to more than one clock. A transfer may start a reporting deadline under one regime, an escalation deadline under an internal standard, and a records retention period under a third, each measured from a different reference point and each expressed in different units. Modelling these as independent timers attached to the event, rather than as a single deadline attribute, keeps them individually auditable and prevents the common defect in which one obligation is satisfied and another silently missed because both were collapsed into a single field.

5. Enabling Technologies

This section characterizes the technology classes available as of 2022 by the architectural requirement each addresses. We deliberately describe capability classes rather than rank products, since the latter dates rapidly and is poorly supported by reproducible evidence.

5.1. Event Streaming Substrate

Distributed, partitioned, replicated commit logs provide the durability, ordering, and replay properties identified in Section 2.1. The design insight underlying this class of system, that the log is a primitive from which both stream and table views are derivable, is directly relevant to compliance because it means the same substrate serves both the real-time detection path and the historical evidentiary record (Badmus et al., 2020; Ladapo et al., 2022).

Retention configuration is a governance decision rather than a capacity decision in this context. A retention period shorter than the required replay horizon eliminates the ability to re-execute revised logic over historical data, which is precisely the capability needed when a rule defect is discovered and a lookback is required (Ladapo et al., 2022).

5.2. Stream Processing Engines

The relevant capability distinctions for compliance workloads are: support for event-time semantics with configurable watermarking and late-data handling; large managed keyed state with durable checkpointing, since behavioral aggregates over long windows across millions of entities are stateful in the extreme; exactly-once or effectively-once processing guarantees; and savepoint or checkpoint mechanisms that permit stateful application upgrade without state loss, which matters because a rule change should not reset the accumulated behavioral baselines that the rule depends upon (Ladapo et al., 2018).

Continuous operator-based engines and micro-batch engines occupy different points on the latency and operational complexity curve, with micro-batch approaches typically achieving second-level rather than millisecond-level latency in exchange for simpler unification with batch processing over the same code (Ladapo et al., 2019).

5.3. Complex Event Processing

Many compliance obligations are inherently sequential rather than aggregate. Structuring is a sequence of related transfers below a threshold; layering is a pattern of order placement followed by cancellation; account takeover is a sequence of credential change, contact detail change, and disbursement within a short interval. Pattern-matching constructs that express sequence, negation, and temporal proximity over event streams express these obligations far more directly than aggregate windowing, and they produce logic that a compliance reviewer can read against the regulatory text (Badmus et al., 2020; Dagodzo et al., 2022; Ladapo et al., 2018).

5.4. Storage and Table Formats

Transactional table formats over object storage, which reached broad production maturity in this period, contribute three properties of specific compliance value. Atomic commits eliminate partially visible states in evidentiary tables. Snapshot isolation with time travel permits reconstruction of the state of a table as of a past point, which directly serves evidentiary reconstruction and reproducible replay. Efficient row-level deletion and update over immutable object storage makes erasure obligations tractable at scale, addressing a requirement that append-only lake designs otherwise satisfy only through expensive full rewrites (Ladapo et al., 2019; Ladapo et al., 2022). The apparent contradiction between immutable evidence and erasure obligations is real and is treated in Section 9.6 (Edivri and Oteri, 2022; Ogbole et al., 2021).

5.5. Policy Engines

General-purpose policy engines evaluating declarative policy against structured input, deployed either as a sidecar or as an embedded library, provide the externalization property required by Layer 3. Their compliance-relevant characteristics are: policy artifacts are text files that can be reviewed, diffed, and version controlled; policies are unit testable in isolation from the application; and evaluation can emit a structured decision log recording which policy rules contributed to a result (Dosunmu and Ogundele, 2020; Dosunmu and Ogundele, 2022).

5.6. Metadata, Catalog, and Lineage Infrastructure

Open lineage specifications that standardize the events emitted by processing jobs, together with metadata platforms that ingest such events into a queryable graph, moved lineage from manual documentation to automatic derivation during this period. The compliance-relevant capability is answering impact and provenance questions programmatically: which downstream regulatory reports depend on this upstream field, and which upstream sources contributed to this reported figure (Badmus et al., 2018; Badmus et al., 2022b). Coverage remains the practical limitation. Lineage automation captures what flows through instrumented engines. Transformations occurring in uninstrumented paths, including business intelligence tool calculations, spreadsheet manipulation, and vendor black boxes, produce lineage gaps precisely at the boundaries where regulated reporting frequently occurs (Badmus et al., 2019b).

5.7. Privacy-Enhancing Technologies

Tokenization and format-preserving encryption permit identifiers to flow through the pipeline in protected form while preserving referential integrity for correlation, which is the specific property that allows behavioral analysis without exposing raw identifiers to every processing stage. Differential privacy and secure multi-party computation appear in the literature of this period principally in the context of cross-institutional collaborative detection, where the privacy barrier between institutions is the obstacle to detecting patterns that are only visible across institutional boundaries. Production adoption for this use case was limited and largely confined to pilots as of 2022 (Dosunmu and Ogundele, 2019; Nnabueze et al., 2021; Yeboah and Ike, 2020).

5.8. Integration, Interoperability, and Migration

Enterprises do not build compliance pipelines on empty ground. They build them beside incumbent systems that are already the control of record, already documented to supervisors, and frequently already the subject of remediation commitments. Migration is therefore a governed process rather than a technical cutover, and the reviewed corpus suggests it is where most programmes lose time (Akinleye and Adeyoyin, 2022a; Amayo et al., 2015). The dominant migration pattern is incremental interception, in which new detection is introduced alongside the incumbent for a defined coexistence period, with both systems running and their outputs reconciled. Coexistence is expensive and organizationally uncomfortable, since it doubles alert volume and forces investigators to work two queues, but the alternative, a direct cutover, requires the institution to assert that the new system is at least as effective as the old one without evidence to support the assertion. Reconciliation during coexistence is the evidence, and the exit criterion should be expressed in terms of coverage comparison rather than elapsed time (Akin-Oluyomi et al., 2020). Reconciliation itself is more difficult than it appears, because the two systems rarely produce comparable outputs. The incumbent may emit one alert per rule per day per customer while the replacement emits signals per event, so equivalence must be established at the level of cases or entities rather than alerts. Where the replacement finds cases the incumbent missed, that is an expected and desirable outcome that nonetheless creates an immediate question about the period during which the incumbent was missing them, which is a lookback obligation with cost and disclosure implications. Programmes that do not anticipate this question tend to discover it at the least convenient moment, and the anticipation should be explicit in the business case rather than discovered during execution (Efobi et al., 2022a). Interoperability considerations shape the technology choices described in Section 5 more than raw capability does. Open serialization formats with registered schemas, open table formats, and standardized lineage events all reduce the cost of replacing a component later, and in a domain where evidence must outlive the systems that produced it, that consideration carries unusual weight. A closed format that no longer has a reader is not merely inconvenient; it may render an institution unable to satisfy an evidentiary request. The corresponding argument for managed proprietary services rests on operational burden, which is real, but the durable artifact should be stored in a format that outlives the service (Okojie and Abioye, 2020).

Enterprise resource planning, service management, and customer relationship platforms complicate the picture because they hold regulated data behind interfaces that were not designed for streaming extraction, and because their vendors control the upgrade cycle. Practical integration typically relies on scheduled extraction or change-log polling, which caps freshness at the polling interval and reintroduces the mixed-freshness problem described in Section 4.1. Where such a platform holds data on the critical path of a real-time control, the achievable control latency is bounded by that platform rather than by the pipeline, a constraint that architecture diagrams routinely omit and that becomes visible only when a supervisor asks how current the screening data was at the moment of a decision (Amayo and Popoola, 2017b).

5.9. Instrumentation and Observability Tooling

The assurance layer described in Section 4.7 depends on instrumentation choices made throughout the pipeline, and those choices have compliance consequences that generic observability practice does not consider (Amayo and Popoola, 2017a; Amayo and Popoola, 2017b; Okoruwa et al., 2020).

Standard telemetry for distributed systems covers metrics, logs, and traces, and all three transfer to compliance pipelines with one important qualification: the telemetry itself may contain regulated data. A trace that carries payload attributes for debugging convenience, or a log line that records a rejected record verbatim, propagates personal data into an observability estate that is typically governed less tightly than the primary data path, is retained under different rules, and is accessible to a wider engineering audience. Several of the access control and classification requirements in Section 7 therefore apply to telemetry, and they are commonly overlooked because telemetry is not perceived as data (Badmus et al., 2018; Mbonu et al., 2019). Beyond generic telemetry, compliance pipelines require domain instrumentation that has no equivalent in ordinary applications. Detector execution counts, evaluated against expected baselines, detect the silent under-detection failure. Enrichment null and default rates detect the substitution failure. Watermark progress per source detects stalled inputs. Alert volume distributions per detector, compared against historical ranges, detect both suppression defects and threshold drift. Reference list version and distribution confirmation, discussed in Section 4.9, detect divergence across screening points. None of these emerge from platform defaults, and each must be deliberately implemented (Amayo et al., 2015; Amayo, 2017).

Synthetic transaction injection deserves particular emphasis as the only instrument that tests the full chain. A set of known-positive cases injected continuously, marked so that they are excluded from regulatory reporting but processed identically in every other respect, produces a direct and continuous measurement of whether the control detects what it is designed to detect. The design difficulty is ensuring that synthetic cases are indistinguishable from real ones to the pipeline while being reliably separable at the case management boundary, and the governance difficulty is ensuring that the exclusion mechanism cannot be misused to suppress genuine cases.

Retention of operational telemetry is a compliance question rather than a cost question, as Section 8.7 argues in the context of coverage demonstration. Metrics retained for thirty days cannot evidence control operation over a two-year examination period, and the aggregate form in which metrics are usually retained may be insufficient if the question concerns a specific interval. Deciding retention on the basis of the evidentiary question rather than the operational one is inexpensive at design time and impossible to correct retrospectively.

6. Automated Risk Monitoring Techniques

6.1. Classifying Detection Techniques

Detection techniques are organized here along four dimensions relevant to pipeline placement: latency profile, state requirement, explainability, and label dependency (Lawal and Oduleye, 2018a; Lawal and Oduleye, 2018b; Tonoyan et al., 2022c).

Table 4 Technique class Latency profile State requirement Explainability Label dependency Deterministic rules and thresholds Sub-millisecond None to low Complete None List and identity screening Milliseconds Reference set Complete None Windowed statistical profiling Milliseconds to seconds High, keyed High None Complex event pattern matching Milliseconds to seconds Moderate, sequence High None Unsupervised outlier detection Seconds Moderate to high Low to moderate None Supervised classification Milliseconds (inference) Feature store Moderate with attribution High Graph and network analytics Seconds to minutes Very high, global Moderate Low to moderate Entity resolution Variable Very high, global Moderate Partial

6.2. Deterministic Rules

Rules remain the backbone of deployed compliance detection, and their persistence is often mischaracterized in the machine learning literature as institutional conservatism. The actual reasons are structural. A rule maps directly and legibly onto a regulatory clause, which makes supervisory defense straightforward. A rule’s behavior is fully specified and testable in advance, so a change can be validated before deployment. A rule produces a complete explanation as a byproduct of execution. And a rule requires no labeled data, which matters acutely because confirmed positive labels in financial crime are extremely scarce, delayed by months, and systematically biased toward what existing rules already detect (Atakpa and Abetoh, 2022).

The known weaknesses are equally structural: brittleness against adaptive adversaries who probe thresholds, high false positive rates, and combinatorial maintenance burden as rule inventories grow into the hundreds without any systematic mechanism for retiring rules whose contribution has decayed (Atakpa, 2021).

6.3. Statistical Baselining

Peer group and self-referential behavioral baselining, where a customer’s current activity is compared against their own historical distribution or against the distribution of a comparable cohort, addresses the fixed-threshold brittleness problem while retaining acceptable explainability. The technique maps naturally onto streaming windowed aggregation and is therefore among the most readily deployed in real-time pipelines (Adenuga, 2022; Atta et al., 2021; Komi and Ganiu, 2022; Sunday and Omoegun, 2022; Tonoyan et al., 2021a; Tonoyan et al., 2022c). Its principal hazard is baseline contamination: if the historical window includes undetected illicit activity, the baseline normalizes that activity and the detector becomes progressively blind to it. Cohort definition is also a fairness-sensitive design choice, since peer groups constructed from proxies correlated with protected attributes can produce differential treatment that is difficult to detect and difficult to defend (Atta et al., 2022; Komi and Adamolekun, 2022; Sunday and Omoegun, 2018; Sunday et al., 2020; Tonoyan et al., 2022a).

6.4. Machine Learning Approaches

Supervised classification for risk scoring is well studied and, on inference latency alone, entirely compatible with real-time placement, since a gradient-boosted tree or comparable model serves predictions in single-digit milliseconds. The obstacles are not computational (Anene and Clement, 2022; Tonoyan et al., 2022b).

Label scarcity and label bias dominate. Confirmed labels are rare, arrive with long delay, and are drawn from the population that existing detection surfaced, which means models trained on them learn to reproduce the current system’s coverage rather than to extend it. Investigator dispositions are a proxy label of uncertain quality (Basnet et al., 2021).

Concept drift is adversarial rather than incidental in this domain. Subjects actively adapt to detection, which means performance degradation is not a slow decay to be corrected on a retraining schedule but a targeted response. This argues for drift detection on both input distributions and output score distributions as a first-class pipeline component rather than an offline monitoring practice (Atakpa and Abolaji, 2022). Explainability under supervisory scrutiny constrains model class selection. Post-hoc attribution methods provide feature-level explanations, but the practical question is whether an institution can defend a decision to a regulator and, in some jurisdictions, to the affected individual. This consideration, combined with model risk governance expectations, explains the frequently observed hybrid pattern: models are used to prioritize, rank, and suppress within a rule-generated alert population rather than to make the primary detection determination. This placement captures efficiency benefits while leaving the defensible rule as the control of record (Tonoyan et al., 2021b).

6.5. Graph and Network Analytics

Several risk typologies are defined by relationships rather than by individual event attributes: layering through intermediary accounts, circular fund flows, shared attributes across nominally unrelated entities, and synthetic identity clusters. Graph representations express these directly, and incremental graph maintenance under streaming updates was an active research area during this period (Dagodzo, 2018b; Dagodzo and Ahiaeke Patrick, 2021a).

The characteristic difficulty is that many valuable graph computations are global rather than local, meaning they require traversal beyond the neighborhood of the updating edge and therefore resist strict real-time evaluation. The observed practical pattern is tiered: maintain the graph incrementally in real time, evaluate cheap local features such as immediate neighborhood risk in the event path, and schedule expensive global computations such as community detection at lower frequency, feeding their outputs back as enrichment attributes for the real-time path (Dagodzo and Ahiaeke Patrick, 2022).

6.6. Entity Resolution

Nearly every technique above depends on knowing that distinct records refer to the same real-world entity. Entity resolution is therefore foundational rather than auxiliary, and errors propagate in both directions with asymmetric consequences: under-linking causes aggregate thresholds to be evaded by fragmentation across unlinked identities, while over-linking merges unrelated parties and produces both false positives and, potentially, unlawful data commingling (Lawal and Oduleye, 2019a; Lawal and Oduleye, 2019b; Lawal and Oduleye, 2021a).

Real-time incremental entity resolution, where a new record must be linked or not linked within the event path, is substantially harder than batch resolution, and the reviewed corpus indicates it remains a common bottleneck in deployed systems (Lawal and Oduleye, 2021b; Medon and Oduleye, 2022).

6.7. Alert Fatigue as a System Property

Reported false positive rates in transaction monitoring commonly exceed ninety percent in practitioner accounts, and while the specific figures are not reproducibly established, the direction is consistent enough across independent sources to treat as a characteristic of the domain rather than as an artifact of particular implementations (Ambali et al., 2021; Arumosoye and Obriki, 2022; Obogo et al., 2019b; Obriki et al., 2022a; Oyeleye et al., 2022). We argue that alert fatigue should be modeled as a system-level resource allocation problem rather than as a detector-level accuracy problem. Investigative capacity is a fixed constraint. Detection systems that generate volume exceeding capacity do not merely waste effort; they degrade the quality of investigation applied to true positives, since triage under overload becomes superficial. This framing reorients optimization from maximizing detection to maximizing true positives investigated within capacity, which is a materially different objective and which justifies techniques such as score-based suppression and consolidation that would appear as coverage reductions under the naive framing (Arumosoye and Obriki, 2018; Eyetsemitan et al., 2021; Obogo et al., 2021; Obriki and Arumosoye, 2019).

6.8. Human Review, Triage, and the Feedback Path

Automated detection terminates in human judgment for every consequential compliance outcome, and the properties of that human stage constrain the analytics that precede it more than the analytics literature usually acknowledges (Arumosoye and Obriki, 2021).

Investigators work a queue. Their throughput is finite, their attention degrades with volume, and their disposition decisions are the only supervised labels the system will ever receive. Three consequences follow. First, queue ordering is a modelling decision with the same importance as detection, since an investigator who works alerts in arrival order rather than risk order will surface fewer true positives per hour regardless of detector quality. Second, the information presented alongside an alert determines disposition quality, and an alert consisting of a rule identifier and a transaction reference forces the investigator to reconstruct context manually, which is both the largest component of handling time and a source of inconsistency. Third, disposition capture must be structured, since free-text closure notes cannot be used to compute precision or to train anything (Obogo et al., 2020c).

Disposition quality is itself uncertain. An investigator closing an alert as unremarkable has not established that no illicit activity occurred, only that the available evidence did not support escalation, and treating such closures as confirmed negatives introduces a systematic bias into any model trained on them. Quality assurance sampling, in which a proportion of closed alerts is independently reviewed, provides a measurement of disposition consistency and is the mechanism by which label noise can at least be estimated. Institutions that sample closures can characterize their label quality; those that do not are training on labels of unknown reliability (Obogo et al., 2019a).

Feedback latency compounds the problem. The interval between an alert and a confirmed outcome, whether that is a regulatory filing, a law enforcement response, or a confirmed loss, is frequently measured in months. Any adaptive system therefore learns from a picture of the world that is substantially out of date, and any evaluation conducted on recent data is evaluating against provisional labels. This is a structural feature of the domain rather than a deficiency in a particular implementation, and it argues for evaluation designs that separate provisional from confirmed outcomes rather than aggregating them (Obriki and Arumosoye, 2018). The organizational design of the investigation function also matters to the technical design. Where investigation is separated into triage and deep review tiers, the pipeline should support two distinct output types with different evidence packaging, since the triage tier needs breadth quickly and the review tier needs depth. Where a four-eyes requirement applies to escalation, the case system rather than the detection system carries that control, and the evidence layer must record both parties. These are not analytical concerns, but they determine what the analytics must produce (Obriki and Arumosoye, 2022).

6.9. Name and Entity Screening

Screening a party against a list is superficially the simplest detection task and in practice one of the most difficult to tune, and it deserves separate treatment because its characteristics differ from the behavioral techniques above (Atima et al., 2022; Sanni and Atima, 2021a; Sanni and Atima, 2021b). The core difficulty is that names are not identifiers. The same individual may appear with different transliterations from a non-Latin script, different orderings of given and family names, honorifics or patronymics present or absent, spelling variants, and abbreviations. Exact matching therefore fails to detect obvious matches, and the necessary response is approximate matching using phonetic encodings, edit distance measures, token-based similarity, or learned similarity models, each configured with a threshold (Akomolafe and Agu, 2019c; Dogbatsey and Ebhojie, 2018). That threshold is the central tuning decision, and it sits on an unusually steep trade-off. Loosening it to catch transliteration variants generates large volumes of coincidental matches against common names, and because the reference lists include many entries with high-frequency name forms, the false positive volume rises much faster than the true positive volume. Tightening it produces a screening control that misses the variants it exists to catch. Neither error is acceptable in the same way: a missed sanctions match is a potential breach with strict liability in some regimes, while an excess of false positives is an operational cost. That asymmetry pushes institutions toward loose thresholds and correspondingly large review queues, which is the principal driver of screening operational cost (Sanni et al., 2020a; Sanni et al., 2020b).

Several refinements moderate the trade-off without altering the threshold directly. Secondary attribute scoring, in which date of birth, nationality, or identifier matches modulate the name score, discriminates among candidates that name similarity alone cannot separate. Cultural name handling, in which matching logic is selected according to the apparent origin of the name, improves accuracy relative to a single global configuration. Whitelisting of previously reviewed and cleared party-to-entry pairs prevents the same false positive from being reviewed repeatedly, which is a substantial efficiency gain, though it requires careful invalidation when either the party record or the list entry changes, since a stale whitelist entry suppresses a match that has become genuine.

Screening also illustrates the evidentiary requirement with unusual clarity. To explain a screening decision an institution must reproduce the list version, the matching configuration and threshold, the computed scores for candidate matches, and the disposition. Because matching configurations are tuned frequently and lists change daily, reproducing a decision from six months earlier is impossible unless all four were captured at the time, and configuration in particular is commonly omitted from evidence capture because it is regarded as infrastructure rather than as a determinant of the outcome.

6.10. Typology Coverage and the Design of Detection

Portfolios Individual detectors are usually evaluated in isolation, but the property that matters to a supervisor is whether the portfolio of detectors covers the risks the institution has itself identified. That mapping, from assessed risk to implemented detection, is where the analytical and the regulatory views of the system meet (Tonoyan et al., 2021a; Tonoyan et al., 2021b; Tonoyan et al., 2022a).

An institution’s risk assessment enumerates the typologies to which it is exposed, given its products, customers, geographies, and channels. Each typology implies a detection requirement, and the portfolio should demonstrably address each one. Expressed as a matrix of typologies against detectors, the mapping makes two things visible that detector-level metrics conceal: typologies with no corresponding detector, which is a coverage gap, and typologies addressed by several overlapping detectors, which is a source of duplicate alerts and inflated volume (Akomolafe and Agu, 2019a; Akomolafe and Agu, 2019b).

Coverage gaps arise more often through drift than through oversight. A new product introduces a channel that existing detectors do not observe, a customer segment expands into a geography whose typologies differ, or a payment mechanism changes the event structure so that an existing rule no longer matches. Because the risk assessment and the detection inventory are usually maintained by different teams on different cycles, the divergence accumulates quietly. Treating the mapping as a maintained artifact, updated when either side changes, converts a periodic discovery into a continuous one (Tonoyan et al., 2022b; Tonoyan et al., 2022c). Overlap is the less obvious problem. Where several detectors fire on the same underlying behavior, alert volume rises without any increase in coverage, and the additional volume consumes the investigative capacity discussed in Section 6.7. Consolidating overlapping detectors, or correlating their signals at the disposition stage described in Section 4.4, reduces volume while leaving coverage intact, and the coverage matrix is what makes the consolidation defensible rather than merely convenient.

The matrix also supports the design justification demand described in Section 8.7. An institution able to show that each assessed typology maps to a named detector, with a recorded rationale for its parameters, is answering the design question directly. One that presents a detector inventory without that mapping is presenting a list of controls whose sufficiency it has not demonstrated, which invites the question of how the list was arrived at.

A final observation concerns typologies that are known but not detectable with available data. Where a risk is assessed as present and no detector can address it because the necessary data is not captured, the honest response is to record the gap and treat it as a data acquisition requirement rather than to deploy a detector that nominally addresses the typology while lacking the inputs to do so. Nominal coverage is worse than acknowledged absence, because it produces an assurance that is not merely absent but false.

7. Enterprise Data Governance Integration

Governance is not a layer in this architecture; it is a plane intersecting all seven layers, and the integration points that follow describe where that intersection has to be operative rather than merely documented. Governance capabilities must be consumed by the runtime path, not merely maintained alongside it.

7.1. Distinguishing Enforcement from Documentation

A simple diagnostic, referred to here as the consumption test, separates governance that enforces from governance that merely records. For each governance artifact the enterprise maintains, identify the runtime component that reads it and changes its behavior accordingly. Artifacts that fail this test, meaning no runtime component consumes them, are documentation. They may still serve audit and communication purposes, but they cannot enforce anything, and they will drift from reality at a rate proportional to the pace of change in the underlying systems (Mbonu et al., 2018; Mbonu et al., 2021).

Applying this test to typical enterprise governance programs is instructive. Data classifications frequently fail it, existing as catalog labels while access control is configured independently by platform teams. Data quality rules frequently fail it, computing scorecards that no pipeline consults before propagating data downstream. Retention policies frequently fail it, existing as written standards with no corresponding scheduled operation (Mbonu et al., 2022).

7.2. Integration Point: Classification Driving

Enforcement Classification passes the consumption test when the classification attribute is read by the policy decision point at query or processing time. Attribute-based access control provides the mechanism: rather than granting access to a named table, a policy grants access to data of a given classification for a given purpose to principals with given attributes, and the classification metadata determines the outcome (Badmus et al., 2019a; Mbonu et al., 2020; Mbonu et al., 2022a).

This inverts the maintenance burden productively. New data assets inherit enforcement from their classification without individual grant configuration, and reclassification propagates automatically. The prerequisite is classification accuracy at a granularity of individual columns and fields, which at enterprise scale requires automated classification with sampling-based validation rather than manual assignment (Badmus et al., 2022a; Mbonu et al., 2019).

7.3. Integration Point: Quality Instrumentation as a

Circuit Breaker Data quality passes the consumption test when quality assertions execute inline in the pipeline and their failure changes pipeline behavior. The design pattern is a validation stage that routes records failing assertions to a quarantine stream rather than propagating them, with quarantine volume itself monitored as a control indicator (Aifuwa et al., 2020; Nnabueze et al., 2021).

The compliance-specific rationale is that silent quality degradation causes silent control failure. If a jurisdiction code becomes null for a subset of records, a geographic risk rule stops matching, detection coverage drops, and nothing in the system reports an error. Inline assertion converts this from an invisible control gap into a visible operational alert. This is the mechanism by which BCBS 239 accuracy and completeness principles become operative rather than aspirational (Ike et al., 2021).

7.4. Integration Point: Lineage as an Operational Query

Surface Lineage passes the consumption test when it is queried by processes that make decisions. Three such processes recur: Impact analysis before change: Before a schema or logic change is deployed, the lineage graph is queried for downstream regulatory consumers, and the presence of such consumers triggers additional review requirements (Dosunmu and Ogundele, 2020; Dosunmu and Ogundele, 2021; Dosunmu and Ogundele, 2022).

Incident scoping: When a data defect is discovered, the lineage graph determines which reports, decisions, and filings were affected and therefore what remediation and notification scope applies. Manual reconstruction of this scope is the dominant cost in data incident response (Borah et al., 2022; Mbonu et al., 2018).

Erasure and restriction propagation: When a data subject exercises rights, the lineage graph identifies every derived location where the subject’s data propagated, including features, aggregates, and model training sets. The third use case exposes the coverage limitation most acutely, since incomplete lineage produces incomplete erasure, which is a compliance failure rather than an inconvenience.

7.5. Integration Point: Purpose Binding

Purpose limitation is the governance requirement least well supported by available tooling as of 2022. Enforcing it requires that access requests carry a declared purpose, that the policy engine evaluate purpose against the lawful basis recorded for the data, and that the declared purpose be recorded in the access log for subsequent audit. Most access control infrastructure of this period authenticates and authorizes principals without any representation of purpose, and the gap is architectural rather than configurational. It remains an open problem, and Section 10.1 returns to it (Sanni et al., 2020a; Sanni et al., 2020c; Sanni and Atima, 2021a; Sanni et al., 2022).

7.6. Organizational Models

Two organizational models appear in the corpus, and the choice interacts with the technical architecture (Akinleye and Adeyoyin, 2021).

Centralized governance places policy authorship, quality definition, and stewardship in a central function. This yields consistency and simplifies supervisory engagement, since there is one authoritative answer, but the central function becomes a throughput bottleneck and typically lacks domain knowledge of individual data assets (Akinleye and Adeyoyin, 2022b).

Federated and domain-oriented governance, articulated in the data mesh formulation that gained prominence during this period, distributes ownership to domain teams under centrally defined and centrally enforced standards, described as computational federated governance. This scales authorship and improves semantic quality but introduces consistency risk (Efobi et al., 2021).

For compliance specifically, we observe that these models are not fully interchangeable. Obligations that are enterprise-wide and legally interpreted, including sanctions, privacy classification, and retention, tolerate federation poorly, because inconsistent local interpretation of a legal obligation is itself a finding. Obligations that are domain-specific and semantically rich, including product-level risk indicators and business quality rules, benefit from federation. The defensible pattern is therefore split by obligation type rather than adopted wholesale, with the enterprise standard for legally interpreted obligations enforced computationally rather than through policy documents (Efobi et al., 2022b).

7.7. Metadata Quality, Catalog Adoption, and the

Economics of Stewardship Every governance integration point described above depends on metadata being present, accurate, and current. That dependency is usually treated as an assumption rather than as a problem to be managed, and it is the most common reason that governance integrations fail after initial deployment (Mbonu et al., 2020; Mbonu et al., 2021a; Mbonu et al., 2021b).

Metadata decays. A classification assigned at onboarding becomes wrong when a field is repurposed, a table is extended, or a downstream copy is created outside the governed path. Because nothing breaks when a classification becomes stale, the decay is silent, and its rate is proportional to the pace of change in the underlying estate. Any design that treats classification as a one-time exercise will therefore degrade toward the documentation condition described in Section 7.1 even if it began as enforcement (Amayo and Popoola, 2017a; Okoruwa et al., 2020).

Two mechanisms counter decay. Automated classification, which infers sensitivity from content and context, scales to the estate but is imperfect, producing both false positives that over-restrict access and false negatives that leave regulated data unprotected. Sampling-based validation, in which a proportion of automated classifications is manually verified, converts an unknown error rate into a measured one and provides the evidence needed to defend the classification programme to a supervisor. The combination is more defensible than either alone, and the measured error rate should be reported alongside coverage rather than suppressed (Mbonu et al., 2019; Mbonu et al., 2022). Catalog adoption is a distinct problem from catalog population. A catalog that is complete but unused by engineering teams does not improve outcomes, because the classification it holds does not reach the systems that would enforce it. Adoption follows from utility rather than mandate, and the utility that reliably drives it is discovery, meaning that engineers use the catalog because it is the fastest way to find and understand data, and governance metadata rides along on that usage. Programmes that lead with obligation rather than utility tend to produce complete catalogs with no consumers. The stewardship economics deserve explicit treatment because they are usually left implicit. Assigning a steward to every regulated data asset produces a workload proportional to asset count, which grows faster than headcount in any active estate. The workload is also unevenly distributed, since a small proportion of assets carries most of the regulatory significance. Prioritizing stewardship by regulatory materiality, so that critical data elements feeding supervisory reporting receive active stewardship while lower-consequence assets receive automated classification and periodic sampling, allocates a fixed capacity against an unbounded demand. This is the same constrained allocation logic that Section 6.7 applies to investigative capacity, and the parallel is not coincidental: governance and investigation are both fixed-capacity human functions attached to an unbounded machine-generated workload.

7.8. Access Control, Segregation of Duties, and Insider

Risk Governance of the pipeline includes governance of access to it, and this dimension receives less attention in the technical literature than its consequences justify (Aifuwa et al., 2020; Filani et al., 2022; Ike et al., 2021).

A compliance pipeline concentrates sensitive material. It holds personal data drawn from across the estate, behavioral profiles, risk ratings, and, critically, the fact that particular parties are under investigation. In many jurisdictions the existence of a suspicious activity report is itself confidential, and disclosure to the subject is an offence. The pipeline therefore holds a category of information whose unauthorized disclosure carries criminal rather than merely regulatory consequence, which raises the required standard for access control above what general data platform practice provides (Dogbatsey et al., 2019; Dogbatsey et al., 2021). Segregation of duties applies in several places. The author of a detection rule should not be the sole approver of its deployment, since a rule can be written to exclude a specific party. The investigator who dispositions an alert should not be able to alter the underlying evidence. The administrator who operates the platform should not be able to read case content, which is achievable through encryption with keys held outside the platform administration boundary but is rarely implemented because it complicates operations. Where these separations are absent, the control depends on the trustworthiness of individuals rather than on the design, which is precisely the dependency that segregation exists to remove (Ike et al., 2022; Nnabueze et al., 2021). Insider risk within the compliance function is uncomfortable to discuss and appears infrequently in the literature, but the concentration of sensitive information and the authority to suppress alerts make it a genuine exposure. The mitigations are conventional: privileged access monitoring, alerting on suppression and whitelist actions, mandatory review of high-value dispositions, and periodic recertification of access. Their implementation is complicated by the fact that the monitoring of the monitors must itself be governed by someone, which in practice places the responsibility with internal audit or an independent risk function rather than within the compliance function.

Access control also interacts with the purpose binding problem described in Section 7.5. Compliance data assembled for monitoring is attractive to other functions, including marketing, collections, and commercial analytics, and requests to reuse it are frequent and often well intentioned. Without purpose as an enforced attribute, the barrier to such reuse is administrative rather than technical, and administrative barriers erode. The clearest architectural expression of purpose limitation is therefore a physical and logical separation of the compliance estate with mediated, logged, and justified access, rather than a shared platform with policy annotations.

8. Evaluation Dimensions and Metrics

The reviewed literature evaluates these systems inconsistently, with technical work reporting throughput and latency while risk analytics work reports detection metrics and neither reporting governance or cost. We propose a consolidated framework across five dimensions.

8.1. Latency and Freshness

Latency metrics characterize whether the pipeline is positioned early enough in the event path for its intended control type, and they are the dimension on which real-time architectures are distinguished from their batch predecessors (Amayo and Popoola, 2017a; Amayo and Popoola, 2017b; Okoruwa et al., 2020). • End-to-end decision latency, measured from business event occurrence to decision emission, reported at high percentiles rather than as a mean, since tail latency determines whether a synchronous control meets its budget. • Ingestion lag by source, reported per source, since aggregate figures conceal a single stalled source. • Watermark lag, indicating how far behind the pipeline’s completeness estimate trails. • Freshness of enrichment reference data, which bounds decision correctness independently of event latency.

8.2. Detection Effectiveness

Detection metrics characterize analytical quality, and their interpretation in compliance settings differs from conventional classification evaluation because the negative class is unverified and the label supply is both scarce and biased (Akomolafe and Agu, 2019a; Akomolafe and Agu, 2019c). • Precision by detector and by disposition, computed against investigator outcomes. • Recall, acknowledged as unmeasurable directly in most compliance contexts and estimable only through proxies such as external referrals, regulatory feedback, red team injection, and retrospective identification of missed cases. • Alert-to-case and case-to-filing conversion rates, which characterize the funnel from detection to regulatory action. • Detection lead time, the interval between the earliest event constituting the pattern and the alert, which is the metric most directly improved by real-time placement and most often omitted from evaluations.

8.3. Governance Coverage

Governance metrics characterize whether the control plane described in Section 7 actually reaches the estate it purports to govern, and they are routinely omitted from technical evaluations despite determining whether detection results can be trusted or defended (Filani et al., 2022; Ike et al., 2022; Yeboah and Ike, 2020). • Classification coverage, the proportion of regulated data assets with current, validated classification. • Lineage coverage, the proportion of regulated data flows with automatically derived, current lineage, distinguishing derived from manually asserted. • Policy enforcement coverage, the proportion of access paths mediated by the policy decision point, since unmediated paths void the control. • Evidence completeness, the proportion of decisions with fully reconstructible evidence chains, measurable by sampled reconstruction attempts.

8.4. Operational Assurance

Assurance metrics characterize the reliability of the pipeline as a control in its own right, addressing the possibility that a system reports no findings because it detected nothing rather than because nothing occurred (Arumosoye and Obriki, 2019; Obogo et al., 2019; Obogo et al., 2020a; Obogo et al., 2021; Obriki and Arumosoye, 2020; Obriki et al., 2022b; Ogbole et al., 2021). • Control uptime, the proportion of time the pipeline evaluated events within its latency budget, which is the correct denominator for control effectiveness assertions. • Synthetic positive detection rate, the proportion of injected known-positive cases detected end to end. • Mean time to detect pipeline degradation, distinct from mean time to detect risk events.

8.5. Economic Dimension

Economic metrics link technical performance to the resourcing decisions that determine whether a detection capability is sustainable at the volumes an enterprise actually generates (Lawal and Oduleye, 2018b; Lawal and Oduleye, 2019b; Lawal and Oduleye, 2021b). • Cost per event processed and cost per true positive identified, the latter being the more decision-relevant figure and the one that exposes the economics of alert fatigue.

• Investigator hours per confirmed case, which links technical performance to the capacity constraint identified in Section 6.7.

8.6. Benchmarking Gap

No standard benchmark exists for real-time compliance pipelines. The obstacles are substantive rather than merely organizational: representative data is confidential and cannot be shared, synthetic data generators that reproduce realistic illicit typologies including adversarial adaptation are not publicly available at sufficient fidelity, and ground truth is unavailable even within institutions. This absence prevents comparative evaluation and is the reason this review cannot rank approaches on effectiveness. We treat it as a first-order research gap (Atima et al., 2022; Sanni and Atima, 2021a; Sanni and Atima, 2021b).

8.7. Evidence Packaging and Supervisory Engagement

Metrics describe the system to its operators. A separate and equally consequential question is what the system produces for an examiner, and the reviewed corpus indicates that institutions frequently discover the gap between the two during an examination rather than before it (Adegbite et al., 2022; Ahmed et al., 2021; Arumosoye and Obriki, 2018). Supervisory engagement makes three distinct demands. The first is explanation of a specific decision, in which the institution must show why a particular transaction was cleared or escalated, using the inputs and logic in force at the time. This is the evidentiary reconstruction described in Section 4.6, and it succeeds or fails on whether enrichment values and rule versions were bound to the event rather than resolved at query time (Mbonu et al., 2020a; Mbonu et al., 2020b).

The second is demonstration of coverage, in which the institution must show that the control operated over the whole population it claims to cover, for the whole period. This is a different artifact, assembled from ingestion completeness records, control uptime, and reconciliation between source system volumes and pipeline throughput. Institutions that monitor pipeline health but do not retain the health record cannot produce this demonstration retrospectively, which converts an operational metric into a retention requirement (Arumosoye and Obriki, 2019; Arumosoye and Obriki, 2020).

The third is justification of design, in which the institution must explain why the thresholds, models, and typologies it selected are appropriate to its risk profile. This is the least automatable of the three and depends on documentation practice: recorded rationale for threshold selection, tuning history with the analysis that supported each change, and traceability from risk assessment to implemented detection. Where that documentation is absent, the institution is in the position of defending a number it cannot explain, which is a common source of findings even when the number is defensible.

A practice that appears in mature implementations is the periodic reconstruction drill, in which a sample of historical decisions is reconstructed end to end as a test of the evidence layer, on the same principle as a disaster recovery exercise. The drill measures something no operational metric captures, namely whether the evidence that theoretically exists can actually be retrieved and assembled by the people who would need to do so under time pressure. It also surfaces format and schema problems while there is still time to correct them, rather than at the point where the reconstruction is being requested by a supervisor.

Machine-readable supervisory reporting, in which authorities consume structured submissions or in some proposals query institutional data directly, was an active area of experimentation during the period reviewed. Its architectural implication is that the reporting boundary moves closer to the pipeline, which raises the quality bar on the intermediate artifacts, since data that was previously reconciled and adjusted during a reporting cycle would instead be exposed with fewer intervening controls.

8.8. Testing, Validation, and Release Practice for

Compliance Logic Compliance logic is software, and it is frequently released with less testing discipline than the systems it monitors, which is difficult to justify given that a defect in the logic produces silent control failure rather than a visible fault (Dagodzo, 2018a; Dagodzo, 2018b; Dagodzo et al., 2022). Unit testing of rule artifacts is straightforward once the logic is externalized as described in Section 4.3, since a rule expressed as a declarative artifact can be evaluated against constructed inputs without deploying the pipeline. The practical obstacle is fixture construction: meaningful test cases require realistic event and enrichment structures, and teams that must hand-construct these tend to test the simple paths and leave the boundary conditions, which is where threshold logic actually fails (Sanni et al., 2020c; Sanni et al., 2022).

Regression testing is more consequential than unit testing in this domain, because the characteristic defect is not that a new rule is wrong but that a change to shared enrichment or a schema modification alters the behavior of unrelated existing rules. A regression suite that replays a fixed corpus of historical events through the full pipeline and compares outputs against a recorded baseline detects that class of defect, and it is the mechanism that makes frequent change safe. Its cost is maintaining the corpus and the baseline, and its difficulty is that a legitimate improvement also changes outputs, so every difference requires adjudication rather than automatic failure (Badmus et al., 2020; Ladapo et al., 2018). Backtesting evaluates proposed logic against historical data to estimate its alert volume and, where labels exist, its precision. It is the principal input to threshold selection and the principal artifact supporting a change approval. Its limitation is the same label bias described in Section 6.8: backtesting against a historical population measures how a new rule would have performed against events that the old rule population defined as interesting, which systematically underestimates what a genuinely novel detector would find. Release practice should reflect the asymmetry between the two error directions. A change that loosens detection, whether by raising a threshold, adding a suppression, or narrowing a scope, reduces coverage and warrants approval at a level commensurate with that reduction, together with a recorded rationale. A change that tightens detection increases operational load but not regulatory exposure, and can proceed on lighter governance provided capacity is available. Treating both directions identically, which is the common default, either over-governs safe changes or under-governs consequential ones.

Finally, the shadow deployment topology described in Section 4.8 is the safest release mechanism available and is underused relative to its value. Running proposed logic in parallel without acting on its output produces exactly the evidence a change approval requires, at the cost of duplicated computation for a bounded period.

9. Cross-Cutting Challenges

9.1. The Semantic Gap

The most persistent difficulty is not technical but interpretive. Regulatory texts are natural language, deliberately general, subject to supervisory interpretation that evolves, and frequently ambiguous at the boundaries where automation must be precise. Converting an obligation into executable logic requires interpretive decisions that are legal judgments, and those judgments are typically made informally during implementation, undocumented, and embedded in code (Mbonu et al., 2020; Mbonu et al., 2021a; Mbonu et al., 2021b).

This creates a traceability failure that surfaces during examination: the institution can show the code and can show the regulation, but cannot show the reasoning that connects them, nor demonstrate that the connection was reviewed by anyone qualified to make it. Maintaining explicit, versioned traceability from regulatory clause through interpretation to implemented rule, with recorded approval of each interpretation, is the mitigation, and it is rarely implemented rigorously (Obogo et al., 2020a; Obogo et al., 2020b).

9.2. Reprocessing with Evidentiary Integrity

When a rule defect is discovered, remediation requires reprocessing historical data under corrected logic. This is straightforward as computation and problematic as evidence, because the reprocessed output must not overwrite or contaminate the original record. The original decision remains the fact of what was decided at the time; the reprocessed result is a separate fact about what would have been decided under corrected logic (Mbonu et al., 2019; Mbonu et al., 2020a; Mbonu et al., 2022). Correct designs treat these as distinct, versioned evidentiary records with explicit linkage, which requires that the evidence store model decisions as immutable versioned facts rather than as current-state records. Systems that treat the alert table as mutable current state cannot satisfy this requirement without redesign (Mbonu et al., 2020b; Mbonu

9.3. Schema Evolution over Long Horizons

Evidence retained for a decade will outlive the schemas under which it was written. Reconstruction requires that the evidence be interpretable under the schema in force at write time, which argues for self-describing formats with embedded schema versions and for retention of the schema registry itself as a first-class evidentiary artifact. Compatibility rules must be enforced at the producer boundary rather than negotiated downstream (Mbonu et al., 2020a; Mbonu et al., 2021a; Mbonu et al., 2022b).

9.4. State Management at Scale

Behavioral aggregates over long event-time windows, maintained per entity across tens of millions of entities, produce operational state in the terabyte range with strict durability requirements. The practical difficulties are recovery time after failure, which sets the control’s downtime, and stateful upgrade, since a rule modification must not discard accumulated baselines. Savepoint-based upgrade with state schema evolution addresses the latter but constrains how state structures may change (Amayo et al., 2015; Amayo, 2017; Oshevire et al., 2017).

9.5. Model Risk Governance for Streaming Models

Model risk management frameworks were designed for models that are developed, validated, approved, and deployed as discrete versioned artifacts with periodic revalidation. Streaming detection models with automated retraining violate every one of those assumptions. The governance question of what exactly was validated when the model changes continuously has no settled answer in the literature or in supervisory guidance as of 2022. Observed practice is conservative, freezing model versions between formal validation cycles and thereby forgoing the adaptivity that motivated the machine learning approach in the first place (Sanni et al., 2020a; Sanni et al., 2020b; Sanni et al., 2020c).

9.6. The Privacy and Surveillance Tension

Data minimization, purpose limitation, and storage limitation obligations conflict directly with monitoring obligations requiring extensive collection, cross-purpose correlation, and long retention. This is a genuine normative conflict, not a technical oversight, and it cannot be engineered away (Liadi, 2022a).

The most acute concrete instance is erasure versus evidence. A data subject requests erasure; the institution holds transaction evidence relevant to a suspicious activity determination. Legal bases exist for retaining data necessary for compliance with legal obligations, but the boundary is not self-executing, and the technical architecture must be capable of implementing selective retention with justification recorded per record rather than blanket retention or blanket erasure. Crypto-shredding, in which per-subject encryption keys are destroyed to render data unrecoverable while preserving structural records, partially addresses this and introduces its own key management and evidentiary questions, since destroyed keys also destroy the institution’s own ability to reconstruct evidence (Liadi, 2022b). Cross-border transfer restrictions add a further constraint that is architectural rather than procedural, since pipeline topology, meaning where processing physically occurs, becomes a compliance determinant (Liadi, 2022c).

9.7. Organizational and Skills Factors

The corpus consistently reports that implementation difficulty is dominated by organizational rather than technical factors. The required combination of regulatory interpretation, risk domain knowledge, distributed systems engineering, and data science rarely exists in a single team, and the functions that hold these capabilities typically report through different executives with different incentives. Compliance functions are evaluated on the absence of findings, which rewards conservatism, while engineering functions are evaluated on delivery velocity. Real-time compliance projects sit precisely on this fault line, and governance structures that do not explicitly reconcile the incentive conflict tend to produce systems that are technically capable and operationally unadopted (Arumosoye and Obriki, 2020; Boakye et al., 2020; Bobga et al., 2018; Eyetsemitan et al., 2020; Eyetsemitan et al., 2022; Obogo et al., 2020b; Obogo et al., 2021; Obogo et al., 2022; Obriki and Arumosoye, 2021; Ogbona et al., 2020a; Oloto and Yeboah, 2022; Orise and Niniola, 2020; Orise and Niniola, 2022; Yeboah et al., 2019).

9.8. Cost Structure, Sustainability, and Vendor

Dependence A real-time pipeline is a permanently running system, and its cost profile differs from the batch systems it replaces in ways that shape long-term viability (Atta et al., 2018). Batch controls consume resources in bounded windows and can be scheduled into low-cost periods. A streaming pipeline consumes continuously, and its floor is set by the state it must hold rather than by the volume it processes. Behavioral aggregates over long event-time windows across a large entity population produce state that must remain resident and durably checkpointed regardless of current throughput, so the quiet hours provide no relief. Institutions that model cost on average event volume rather than on state footprint consistently underestimate (Atta et al., 2020). Evidence retention is the second structural cost, and it grows monotonically. Retention horizons set by statute frequently exceed the operational life of the pipeline, so the retained volume accumulates across successive system generations. Tiered storage, in which recent evidence remains in queryable form and older evidence moves to cheaper archival storage with slower retrieval, is the standard resolution, and its design constraint is the retrieval time an evidentiary request tolerates. An archive that satisfies a thirty-day supervisory request may be unusable for a five-day one, so the tiering policy is a compliance decision rather than an infrastructure decision (Sunday and Omoegun, 2019). The third cost is human and is usually the largest. Rule authorship, tuning, model validation, investigation, and the governance functions described in Section 7 all consume specialist capacity that is scarce and does not scale with automation in the way that compute does. Automation shifts the human cost rather than removing it, moving effort from alert handling toward tuning, validation, and evidence work. Business cases predicated on headcount reduction therefore tend to disappoint, while those predicated on capacity redeployment toward higher-value review are more defensible against subsequent scrutiny (Sunday et al., 2019). Vendor dependence interacts with all three. Managed streaming, detection, and governance services reduce operational burden substantially and are the pragmatic choice for most institutions, but they introduce a dependency on a commercial relationship for a function the institution cannot lawfully suspend. Three mitigations recur: retaining evidence in open formats readable without the vendor, maintaining sufficient internal understanding of the detection logic to reconstruct it elsewhere, and negotiating data extraction rights explicitly rather than relying on standard terms. The concentration risk when many institutions depend on the same small set of providers was, during the period reviewed, an emerging supervisory concern in its own right rather than merely a commercial consideration.

The cost measure that best supports decision-making is cost per true positive investigated, introduced in Section 8.5, because it links infrastructure spend to the outcome the control exists to produce. Measured that way, investments that reduce false positive volume frequently dominate investments that increase raw detection capability, since the marginal true positive surfaced by a broader detector is expensive if it arrives inside a large volume of noise that consumes investigative capacity.

9.9. Data Localization and the Geography of Processing

Where processing physically occurs is a compliance determinant rather than an infrastructure preference, and this constraint shapes pipeline topology in ways that generic architectures do not anticipate (Dosunmu and Ogundele, 2019; Dosunmu and Ogundele, 2020; Yeboah and Ike, 2020). Several regimes restrict the transfer of personal or financial data across borders, whether through general adequacy and transfer mechanisms, sector-specific requirements that certain records remain within a jurisdiction, or supervisory expectations that data required for local supervision be locally accessible. The practical effect is that a single global pipeline processing all events in one region may be unlawful for a subset of those events, and the subset is determined by attributes of the data rather than by the system boundary (Aminu-Ibrahim et al., 2020; Ogbete et al., 2018). Three topologies appear in response. Regional pipelines process locally and share only aggregates or metadata, which satisfies localization cleanly but fragments the behavioral state that cross-border typologies depend on, since a pattern spanning two regions is visible in neither. Central processing with regional preprocessing removes or tokenizes restricted attributes before transfer, preserving correlation on tokenized identifiers while keeping identifying data local, which is the most common compromise and which depends on the tokenization scheme being consistent across regions and its key material being managed under the stricter regime. Full central processing under transfer mechanisms is simplest architecturally and carries the greatest legal exposure, since the validity of the transfer mechanism may change during the operational life of the system, as the period reviewed demonstrated repeatedly (Dosunmu and Ogundele, 2021; Dosunmu and Ogundele, 2022).

The topology choice interacts with the evidentiary requirement. If evidence must be retained locally, the evidence layer is regionally partitioned even where processing is central, and reconstruction of a cross-border case requires assembly from multiple stores under different retention rules. If a regional store must be purged under a local retention limit that is shorter than the retention period the institution’s home supervisor expects, the two obligations conflict directly and the resolution is legal rather than technical.

Operational resilience requirements add a further constraint by expecting that critical functions remain available under regional disruption, which pushes toward replication, while localization pushes against it. The resolution generally involves replicating within a jurisdiction rather than across, which raises cost and reduces the resilience benefit that global distribution would otherwise provide. The general observation is that pipeline topology encodes legal decisions. An architecture diagram that shows a single processing region for a multinational institution is making a claim about lawful transfer whether or not anyone involved in drawing it intended to make one, and that claim should be reviewed by people qualified to assess it.

10. Discussion

10.1. Problems That Remain Unresolved

Eight problems recur across the corpus without settled answers, and they are set out here in rough order of tractability (Mbonu et al., 2019; Mbonu et al., 2022a; Mbonu et al., 2022b).

Regulatory intent representation: Formal, machine-processable representations of regulatory obligations that preserve traceability from clause to executable rule, support versioning as interpretations evolve, and permit automated consistency checking across a rule inventory. Progress here bears directly on the semantic gap described in Section 9.1, and it is the problem whose resolution would most improve supervisory defensibility (Sanni et al., 2022). Benchmarking and synthetic data: Open benchmarks with realistic synthetic data reproducing illicit typologies and adversarial adaptation, enabling the comparative evaluation that the field currently cannot perform (Dagodzo and Ahiaeke Patrick, 2020; Dagodzo and Ahiaeke Patrick, 2021a). Evidence-preserving reprocessing: Formal semantics and reference implementations for retroactive re-evaluation that maintain the evidentiary distinction between original and corrected determinations, with linkage sufficient for supervisory explanation (Badmus et al., 2018; Badmus et al., 2019a).

Purpose-aware access control: Access control models and implementations in which purpose is a first-class evaluated attribute rather than an out-of-band assumption, closing the gap described in Section 7.5.

Streaming model risk governance: Frameworks reconciling continuous model adaptation with validation and approval requirements, potentially through validated adaptation envelopes within which retraining is pre-authorized and outside which formal revalidation is triggered. Real-time incremental entity resolution: Methods achieving acceptable accuracy under event-path latency constraints, with principled handling of resolution revision, including retroactive correction of decisions made under superseded linkage.

Privacy-preserving cross-institutional detection: Practical deployment of secure computation and federated approaches for typologies visible only across institutional boundaries, moving beyond the pilot stage documented in this period. Capacity-aware detection optimization: Formal treatment of detection as constrained resource allocation under fixed investigative capacity, replacing detector-level accuracy optimization with system-level optimization of true positives actually investigated.

10.2. Limitations

Four limitations qualify the account given here. Reliance on practitioner literature for implementation evidence introduces publication bias toward successes, since failed implementations are not documented and the reported patterns may therefore reflect survivorship rather than efficacy; restricting such sources to questions of feasibility mitigates but does not remove the bias (Ahiaeke Patrick et al., 2020; Ilodigwe and Adesemoye, 2021; Okonkwo et al., 2019).

The evidence base is also heavily weighted toward financial services, where regulatory intensity and data volume jointly justify investment. Generalization to healthcare, energy, telecommunications, aviation, and other regulated sectors rests on architectural argument rather than demonstrated equivalence, and sector-specific obligations may invalidate parts of the architecture described in Section 4 (Aminu-Ibrahim et al., 2020; Michael and Ogunsola, 2021a; Ogunwole et al., 2021).

The 2022 boundary excludes subsequent developments. Given the pace of change in both regulatory expectations around algorithmic accountability and in machine learning capability, statements about technology maturity are time-bounded, though the architectural and governance observations should prove more durable than the technology characterizations (Michael and Ogunsola, 2021d; Ogbete et al., 2020; Okonkwo et al., 2021).

Finally, this is a synthesis rather than a study. No statement here is supported by original measurement, and the absence of a common benchmark means the synthesized claims cannot be validated comparatively even in principle with the evidence currently available (Ilodigwe and Adesemoye, 2019b; Michael and Ogunsola, 2022b; Okonkwo et al., 2018b).

10.3. Implications for Practice

Several implications follow from the preceding analysis that are actionable without waiting for the open problems to be resolved (Mbonu et al., 2021; Mbonu et al., 2022a; Mbonu et al., 2022b).

Build the evidence layer first. It is the least glamorous component and the one most frequently deferred, and deferring it is expensive because retrofitting provenance onto a pipeline that was not designed to carry it requires reworking every stage. A pipeline with modest detection and complete evidence can be improved incrementally; a pipeline with sophisticated detection and no evidence cannot be defended at all (Arumosoye and Obriki, 2021; Arumosoye and Obriki, 2022).

Bind enrichment to event time from the outset. The temporal consistency requirement described in Section 4.2 is cheap to satisfy in a new design and extremely expensive to introduce later, because it changes the shape of the reference data stores rather than the logic that reads them (Ogbete et al., 2019; Ogbete et al., 2020).

Externalize policy before the rule inventory grows. The argument for versioned, independently deployable rule artifacts is strongest when there are few rules, because that is when migration is feasible. Institutions typically reach for externalization after the inventory has grown to a size where the migration itself is a multi-year programme (Badmus et al., 2018; Mbonu et al., 2019).

Instrument quality inline rather than reporting on it. The distinction developed in Section 7.3 is the difference between a scorecard that documents degradation and a circuit breaker that prevents it from propagating into a control determination. Measure control uptime and defend it as a first-class metric. The proportion of time a control actually operated within its latency budget is the correct denominator for any statement about control effectiveness, and it is rarely reported. Apply the diagnostic in Section 7.1 to the existing governance inventory before commissioning new governance work. The exercise is inexpensive and frequently reveals that the constraint is not missing metadata but metadata that nothing consumes, which is a different and usually cheaper problem to fix.

Treat detection tuning as a capacity allocation exercise rather than an accuracy exercise. Framing it that way, as argued in Section 6.7, makes suppression and consolidation defensible rather than suspicious, because the objective becomes true positives actually investigated rather than alerts generated. Finally, plan the lookback before deploying improved detection. Better detection applied to current events raises an immediate question about past events, and institutions that have not decided in advance how they will answer it tend to answer it under pressure and without adequate resourcing.

10.4. Directions for Empirical Work

The problems set out above are largely conceptual and architectural. A separate agenda concerns measurement, and it is tractable with existing methods provided the access problem can be solved (Lawal and Oduleye, 2018a; Lawal and Oduleye, 2018b; Lawal and Oduleye, 2019a). Comparative effectiveness studies are the most obvious absence. No published work in the reviewed corpus compares detection approaches on a common population with a common label definition, which means that claims about the superiority of any technique rest on internal evaluations that cannot be inspected. Multi-institution studies conducted under a shared protocol, with results reported in aggregate to protect commercial and supervisory sensitivity, would establish comparability without requiring data sharing (Badmus et al., 2019a; Badmus et al., 2019b). Latency and outcome studies would test the premise on which the entire architecture rests, namely that earlier detection produces better outcomes. That premise is plausible and widely assumed but rarely measured, and the measurement is feasible where detection lead time and recovery or prevention outcomes are both recorded. A finding that outcomes are insensitive to lead time beyond some threshold would have substantial design implications, since it would suggest that investment should move from latency reduction toward precision (Aminu-Ibrahim et al., 2018; Aminu-Ibrahim et al., 2019).

Investigator studies would address the human stage described in Section 6.8. Questions about how alert presentation affects disposition accuracy, how queue ordering affects true positive yield, and how volume affects error rates are amenable to conventional experimental methods and are almost entirely unaddressed in the compliance context, though the parallel literature in security operations offers a template (Lawal and Oduleye, 2019b; Lawal and Oduleye, 2021a).

Cost and sustainability studies would test the economic claims in Section 9.8. Longitudinal accounting of total cost per confirmed outcome across the life of a monitoring programme, including the human functions that automation shifts rather than removes, would either support or undermine the business cases on which these programmes are approved. Finally, governance adoption studies would test whether the integration points in Section 7 actually change outcomes. The claim that enforcement-integrated governance outperforms documentation-based governance is argued here from mechanism rather than from evidence, and it is measurable through comparison of incident rates, remediation scope, and examination findings across institutions with differing governance architectures.

Two further studies would test claims that this review makes but cannot substantiate. The first concerns the placement question, comparing institutions that positioned equivalent controls preventively against those that positioned them detectively, holding the detection logic constant, in order to isolate the effect of placement from the effect of technique. The second concerns coverage measurement, testing whether the synthetic injection method described in Section 5.9 produces estimates of detection coverage that correspond to independently established outcomes, since the method is widely recommended and its validity has not been demonstrated.

Access is the binding constraint on all of this work. The data is confidential, the outcomes are sensitive, and institutions have limited incentive to expose comparative performance. Supervisory bodies are the actors best positioned to resolve this, since they already receive comparable information across institutions and could commission or publish aggregate analysis without exposing individual performance. Where that route has been taken in adjacent domains, notably in operational risk and in safety reporting, it has produced evidence bases that no individual institution could have assembled alone.

11. Conclusion

Real-time compliance pipelines represent the migration of regulatory control from the reporting layer into the operational data path. The motivation is structural rather than fashionable: when business events complete in seconds, controls that evaluate in days can document but cannot prevent.

The technical foundations are mature. Durable replayable logs, event-time stream processing with exactly-once semantics, transactional table formats supporting time travel and row-level deletion, externalized policy engines, and automatically derived lineage are all available and production-proven. An organization that fails to build a real-time compliance capability in 2022 does not fail for want of infrastructure.

The binding constraints lie elsewhere, and they are of two kinds. The first is semantic. Translating natural-language obligations into executable, versioned, defensible logic remains a manual, undocumented, and interpretively fragile process, and the resulting traceability gap is the most common point of supervisory challenge. The second is integrative. Governance capabilities are widely maintained as documentation that no runtime component consumes, and a classification that no policy engine reads, a quality rule that no pipeline consults, and a lineage diagram that no impact analysis queries provide assurance without providing control. The diagnostic set out in Section 7.1, which asks of each governance artifact which runtime component reads it and changes behavior accordingly, addresses the second constraint at low cost and is the most useful single question an organization can ask of an existing governance program. For the first constraint, regulatory intent representation remains the highest-value target.

The wider implication is that the field’s centre of gravity should shift from detection sophistication toward the unglamorous problems of traceability, evidence, and enforcement integration. A modest detector whose decisions can be reconstructed, explained, and defended is worth more in this domain than a superior detector whose decisions cannot.