The Agentic Compliance Playbook: Implementing Continuous KYA and BSA Verification

Strip the dollar figure out of the UBS enforcement action and what remains is an architecture finding. FinCEN assessed a $125 million civil money penalty against UBS for Bank Secrecy Act failures that persisted across years of scheduled reviews, periodic audits, and calendar-driven refresh cycles. The controls existed on paper. They simply could not see risk at the speed risk now moves. Every institution that verifies identity once at onboarding and re-checks it on a fixed schedule carries the same structural exposure, whatever its policy binder says.

The second signal arrived from the analyst side. Gartner's 2026 identity verification Magic Quadrant elevated Know Your Agent (KYA) and agentic identity from emerging themes to core evaluation criteria, formal recognition that autonomous AI agents now open accounts, move funds, and file documents on behalf of verified humans. A compliance stack that can prove who onboarded but not who is acting fails the question examiners are now trained to ask. Our KYA hub covers the standard in depth; this playbook wires it into a working BSA program.

Taken together, the two signals define the target architecture: identity verified at the client edge in under 150 milliseconds, monitored continuously rather than periodically, extended to every delegated AI agent, and documented in an audit fabric that produces evidence on demand. The five phases below build that architecture in order.

**Phase 1: Hardening Client Ingestion and Sensor Provenance**

Evaluating identity documents via cloud OCR introduces processing latency and leaves applications vulnerable to virtual camera scripts operating behind mobile web interfaces. Verification engines must evaluate device telemetry and hardware signatures directly at the point of interaction.

The failure pattern is consistent. A fraud operator runs a virtual camera driver behind a mobile web session, feeds a synthetic face or a replayed document capture into the browser stream, and the cloud pipeline downstream faithfully processes imagery it had no way to authenticate. Post-capture analysis can score the pixels, but it cannot testify to the sensor. Provenance has to be established where the photons hit the hardware, which means the first verification layer belongs on the client.

**The Client-Edge Verification Matrix: three client-side attestation layers**

Hardware Enclave Attestation. Execute a cryptographic challenge with the device's secure enclave to confirm incoming data originates from a physical camera sensor. Review integration specifications on our Technology Hub. The challenge-response happens below the application layer, so an emulator or virtual driver cannot forge the answer without defeating the silicon itself.

Verifiable Credential Ingestion. Utilize the Arc gateway to ingest eIDAS 2.0 attributes and biometric eID credentials via the Arc Gateway. Wallet-issued attributes arrive already signed by the issuing authority, which lets the engine skip redundant document capture entirely for credentialed users while keeping the cryptographic chain intact.

Sub-150ms Execution Boundary. Complete all client-edge telemetry and liveness checks within 150 milliseconds to eliminate onboarding friction and user drop-off. Pair the boundary with face liveness and deepfake detection models compiled for on-device execution, so the latency budget covers the full presentation-attack surface rather than a subset of it.

The pitfall in Phase 1 is partial coverage. Teams attest the native mobile app and leave the mobile web flow on legacy cloud capture, and the fraud traffic migrates to the weaker door within days. Enforce the same attestation matrix on every ingestion surface, and treat any channel that cannot meet the 150 millisecond boundary as a gap to close, not an exception to document.

**Phase 2: Deploying Autonomous Compliance Agents**

Static database matching executed on fixed calendar schedules cannot keep pace with evolving transaction velocities or delegated AI agent actions. Autonomous agents deliver continuous monitoring and real-time threat containment.

This is the layer where the UBS lesson lands hardest. A monthly batch job re-screens the customer file against a watchlist that changed three weeks earlier. A quarterly review re-scores a risk profile that a burst of transaction velocity invalidated in an afternoon. Continuous supervision means the compliance logic runs as a resident process, evaluating events as they occur, and the practical way to build it is to assign the work to purpose-built agents.

Pull quote

“A compliance program that verifies identity once and monitors on a calendar is not a control. It is a snapshot of a control, aging from the moment it is taken.”

— deepidv Compliance Practice

**Operational Role Blueprint for Luna and Arbiter**

Luna (Compliance Overseer). Ingests global sanctions, FinCEN regulatory filings, and watchlist updates in real time, automatically adjusting risk-scoring rules and audit trails. Learn more at Luna. Wire Luna directly into sanctions list screening, PEP screening, and transaction monitoring so a watchlist delta propagates to every affected account and agent within minutes, not at the next batch window.

Arbiter (Autonomous Red Agent). Executes continuous red-team simulations against onboarding and payment endpoints, testing edge defenses against emulators and unauthorized AI agent requests. Explore Arbiter. The adversarial pressure justifies the investment: leading verification providers moved to add AI media detection across more than 6 billion annual identity checks precisely because generative attack tooling now iterates faster than any manual test calendar.

Phase 2 also extends supervision to non-human actors. Every AI agent that acts on a customer's behalf must be bound to a verified human root of trust and governed under Know Your Agent rules: scoped permissions, continuous behavioral evaluation, and instant revocation when a binding degrades. Luna treats a delegated agent the same way she treats a human account, as a monitored identity with a risk score that moves.

Two pitfalls dominate agent deployments. The first is advisory-only wiring: if Luna can flag but not act, you have built an alarm, not a control, so give her revocation and hold authority with human confirmation for high-impact cases. The second is testing Arbiter against staging only. Adversaries attack production, and an edge boundary that has never been probed under production conditions is an assumption, not a defense.

**Phase 3: Building the Proof and Audit Architecture**

The first two phases verify and monitor. Phase 3 makes the results provable, and provability is where BSA programs actually fail. The UBS action was not triggered by a missing policy; it was triggered by outcomes the program could not demonstrate. An examiner who asks what your monitoring caught last Tuesday does not want a description of the process. She wants the record.

**The append-only decision log**

Every verification verdict, sanctions re-screen, risk-score movement, agent action, and revocation writes to a persistent, append-only decision log. Each entry answers four questions: which identity acted, which verified human it traces to, what control evaluated the event, and what verdict applied at that moment. Because the log is immutable and time-ordered, the complete provenance of any decision can be reconstructed months later without regenerating evidence from fragile snapshots.

**Event-driven re-verification**

Calendar-based reKYC dies in this phase. Re-verification triggers on material events instead: a watchlist delta touching a matched profile, a transaction velocity spike, a device or credential change, a new agent delegation, a corporate registry update on a business customer. Each trigger re-runs only the affected checks, keeps KYC compliance records current by construction, and writes its own justification into the decision log. The scheduling calendar survives only as a backstop ceiling, not as the primary control.

Luna also drafts the narrative artifacts the program owes regulators. When a monitoring chain crosses the suspicious-activity threshold, she assembles the timeline from the decision log, attaches the triggering events and control verdicts, and routes a pre-structured filing narrative to the human analyst for judgment. Analysts stop reconstructing history and start deciding, which is the correct division of labor between agent and officer.

**Phase 4: Rollout and Migration**

Nobody deploys this architecture into a vacuum. The realistic starting point is a legacy stack: a point-in-time onboarding vendor, a batch sanctions job, a quarterly review calendar, and a case queue with a backlog. The migration pattern that works runs in four gates, and the discipline is refusing to skip one.

Gate one: shadow mode. Run the continuous engine in parallel with zero enforcement authority. Every event flows through both stacks; the new engine writes verdicts to its decision log while the legacy stack keeps deciding. Shadow mode surfaces integration defects and baseline disagreement rates while the blast radius is zero.

Gate two: calibration. Compare shadow verdicts against legacy queue outcomes and tune risk scoring thresholds until disagreements are explained, not just counted. A continuous engine that inherits a legacy stack's false positive rate has automated the wrong thing faster.

Gate three: gated cutover. Route new onboarding through the continuous engine first, since new accounts carry no legacy state to reconcile. Then migrate lifecycle events cohort by cohort, watchlist rescreens before transaction triggers, keeping the legacy path warm as a rollback target for each cohort until its evidence parity is proven.

Gate four: decommission. Retire the batch jobs only when the decision log demonstrates parity or better on every control the legacy stack owned. Decommissioning is an evidence decision, not a schedule decision.

The migration pitfall is the permanent parallel run. Shadow mode is seductive because it defers every hard decision, and programs sit in it for quarters while paying for two stacks and defending neither. Set exit criteria for each gate before entering it, and treat a gate that cannot be exited as a finding about the architecture, not a reason to wait.

**Phase 5: Measurement and Regulator Readiness**

A continuous program earns its keep in the metrics it can put in front of a supervisor. Instrument six from day one: p95 client-edge verification latency against the 150 millisecond budget, watchlist-delta-to-rescreen propagation time, agent revocation latency, false positive trend by cohort, suspicious-activity narrative timeliness, and Arbiter finding closure time. Numbers that improve quarter over quarter are the difference between a program that claims maturity and a program that demonstrates it.

Pull quote

“Examiners no longer ask whether you have a monitoring process. They ask what it caught, when it caught it, and what happened in the ninety seconds after.”

— deepidv Regulatory Practice

Deadlines sharpen the point. Institutions touching payment stablecoin flows face FinCEN's August 21 GENIUS Act CIP compliance date, and the outcomes-based posture regulators are converging on globally means the same evidentiary standard is arriving for everyone else on a shorter fuse than most roadmaps assume. Building the decision log now is cheaper than reconstructing history under an examination letter.

**The examiner walkthrough**

Rehearse the walkthrough end to end before anyone official requests it. From the decision log, produce the monitored population including every bound AI agent, the verified human behind each binding, the controls that fired in a chosen week, the propagation time for a specific watchlist delta, and one full suspicious-activity narrative from trigger to filing. If any step requires manual reconstruction, that step is the next engineering ticket.

Build the five phases in order and the $125 million lesson becomes someone else's case study. Identity is verified at the sensor in under 150 milliseconds, monitored continuously by Luna, stress-tested continuously by Arbiter, extended to every delegated agent under KYA governance, and documented in a record that answers examiners on demand. Point-in-time compliance was defensible when risk moved at the speed of paperwork. It does not anymore, and the institutions that internalize that first will spend the next examination cycle explaining their architecture instead of their exceptions. Explore the full agents platform or start with continuous monitoring to scope the deployment.