Compliance programs evolve as businesses grow. AML/KYC policies, onboarding procedures, and transaction monitoring rules may all need updating as the company enters new markets, identifies new threats, or its risk appetite changes. The challenge is getting those pieces to work as one system.
This guide focuses on the operational side of compliance: assigning responsibilities, putting policies into practice, setting up checks and investigations, and keeping records that can stand up to an audit.
Key takeaways:
-
Start with a risk assessment and define which customers, activities, and jurisdictions the business is prepared to accept
-
Assign clear responsibilities and document how customer verification, monitoring, investigations, and escalations should work
-
Connect compliance tools, maintain an audit trail, and use quality reviews to improve controls as risks change
What does an effective compliance program need?
A bank, crypto platform, marketplace, and gambling operator will face different risks, regulatory requirements, and operational constraints. The building blocks, however, are fairly consistent. A typical compliance program needs four things:
-
People who own specific processes
-
Policies that translate regulatory requirements into day-to-day procedures
-
Tools that support checks, such as identity verification, screening, and transaction monitoring
-
Processes for escalating unusual cases, documenting decisions, and reviewing whether controls still work as intended
These parts are closely connected. Risk appetite shapes your desired client base. Risk assessment determines which controls are needed. Those controls shape onboarding, monitoring, and escalation procedures. Technology helps apply them consistently, while records make the process auditable and easier to review later.
However, before the rest of the program can take shape, the business needs a clear view of its risks. Those risks shape which controls are needed and how the compliance program is designed.
Start with the risks your business actually has
Risk assessment starts with the business model. A cross-border payments provider needs to consider sanctions exposure and suspicious transaction patterns. An online retailer selling alcohol faces age-verification requirements. The risks, and therefore the required controls, will be different.
To assess the company's exposure, consider:
-
Customer base: Will the business serve individuals, companies, or both, and which customer categories will it accept? For example, will it onboard politically exposed persons (PEPs), companies from offshore jurisdictions, or businesses with complex ownership structures?
-
Products and activities: Cross-border transfers, cryptocurrency transactions, complex financial instruments, age-restricted sales
-
Delivery channels: Remote onboarding, in-person verification, services offered through intermediaries
-
Geography: Where the company operates and its customers are located, including sanctions restrictions and local regulatory requirements
This assessment helps determine which controls belong in the compliance program, such as identity and age verification, sanctions screening, KYB checks, or transaction monitoring.
The next level is assessing individual customers and activities. For example, a potential PEP match may call for additional due diligence, while unclear beneficial ownership may require further evidence before a business can be onboarded. These findings affect which checks are performed and how closely activity is monitored afterwards.
This is the basis of a risk-based approach: the controls applied depend on the level and type of risk associated with a particular customer or transaction.
Customers are often classified as low, medium, or high risk. Higher-risk relationships generally require enhanced due diligence (EDD) and may also involve a second reviewer (the four-eyes principle) or senior management approval.
Assign ownership and escalation paths
Each core compliance process needs a clear owner, along with rules for when a case moves to another team or level of review.
A typical split may look like this:
| Function | Main responsibility | Typical escalation point |
|---|---|---|
| KYC | Onboarding and screening of individual customers | Higher-risk customers, identity inconsistencies, screening hits |
| KYB | Onboarding and due diligence of businesses | Complex ownership structures, high-risk entities or jurisdictions |
| Transaction monitoring | Monitoring customer activity and financial flows | Unusual activity, potential fraud indicators, or suspected money laundering and terrorist financing |
| Investigations | Reviewing complex or escalated cases | Cases that may require a suspicious activity/transaction report (SAR/STR), account restrictions, or senior approval |
| Law-enforcement requests | Handling requests from authorities | Requests requiring validation, legal review, or disclosure decisions |
| Compliance Officer / MLRO | Compliance oversight and regulatory obligations | Material compliance risks, reportable activity, policy exceptions |
| QA / QC | Checking the quality and consistency of compliance work | Repeated errors, weak controls, or procedural gaps |
| Internal audit | Testing whether controls and procedures remain effective | Findings that require policy, process, or system changes |
Beyond these day-to-day responsibilities, the program needs management oversight. Senior management oversees the compliance framework, ensures adequate resources, and reviews significant risks and failures.
The escalation procedure also determines who has authority to make the final decision, and how quickly the case must be reviewed. Similar rules can be established for suspicious transactions or unclear beneficial ownership, with different triggers and approval requirements.
Turn regulatory requirements into actual procedures
Under AML/KYC requirements, higher-risk customers generally require enhanced due diligence. Onboarding procedures should explain what additional documents to request, when another employee needs to double-check the case (the maker-checker principle), and which decisions require senior management approval.
Depending on the business, the internal documentation may include:
-
AML/KYC policy: The overall framework for customer acceptance, due diligence, screening, monitoring, and reporting
-
Risk appetite statement: A document defining the types and levels of risk the organization is prepared to tolerate
-
Permitted and restricted country lists: Operational rules for dealing with particular jurisdictions
-
Process procedures: Step-by-step rules for onboarding and identity verification, screening, transaction monitoring, and other recurring processes
-
Conduct policies: Rules covering conflicts of interest, gifts, and, where relevant, insider trading and other employee conduct restrictions
-
Whistleblowing procedures: Instructions on reporting suspected wrongdoing
-
Industry-specific policies: For example, responsible gambling rules covering limits and self-exclusion
Some organizations publish parts of their compliance documentation.
For example, Recapita Finance's KYC & AML Policy covers customer acceptance, identification, due diligence, and transaction monitoring. It also defines customer risk categories and different schedules for updating KYC information.
UniCredit's Conflict of Interest Policy explains how potential and actual conflicts are identified, recorded, and managed, including when disclosure to customers is necessary.
Revolut's Whistleblowing Policy describes its confidential reporting channels, the option to report anonymously, and protections against retaliation.
These public documents offer a look at how companies formalize their compliance requirements. The day-to-day procedures behind them, however, usually remain internal.
Recapita Finance’s KYC & AML Policy includes its approval date, version, owner, and regulatory references, showing who owns the policy and which regulations it follows.
Choose and connect your compliance tools
There are already tools for most routine compliance checks, from verifying identity documents to screening customers and tracing transactions. The job is to put together a toolkit that fits the business.
A crypto exchange and a traditional bank won't necessarily need the same tools, and buying several specialized services is only part of the equation. Their results also need to feed into the company's existing compliance processes.
Depending on the business, the toolkit may include:
| Compliance task | What the tools handle | Example providers |
|---|---|---|
| Identity verification and identity fraud prevention | Document and biometric verification, geo/IP/device risk signals, fraud detection, risk-based workflows, case management, and audit trails | Regula IDV Platform |
| Sanctions, PEP, and adverse media screening | Watchlist checks, potential match detection, ongoing screening | LexisNexis |
| Fiat transaction monitoring | Rule-based alerts, behavioral anomaly detection, case management | Sardine, Feedzai, ComplyAdvantage |
| Blockchain transaction monitoring | Crypto transaction tracing, wallet risk analysis, suspicious activity alerts | Chainalysis KYT |
| KYB and corporate due diligence | Business registration checks, company verification, beneficial ownership research | iDenfy, Trulioo |
| Law-enforcement request management | Request verification, secure document exchange, request tracking | Kodex |
These functions don't always require separate tools. For example, Regula IDV Platform combines document and biometric verification with AML/PEP screening through integrated services. It also supports connections to other third-party providers, allowing businesses to incorporate additional checks into the same workflow.
How the tools exchange information deserves just as much attention as their individual capabilities. Preserving the source and context of each result helps protect identity signal integrity across systems. It also allows reviewers to compare findings, spot inconsistencies, and trace decisions back to the original evidence during an audit.
Set up automated checks and case management
Once the tools are connected, the next step is to configure the processes they will support. At the customer level, there are at least five recurring activities worth automating:
-
Customer risk scoring: Define which factors contribute to the score, how much weight they carry, and what happens when a customer crosses a risk threshold. Scores can be recalculated when customer information or circumstances change. See our guide to risk-based KYC for an example of scoring logic.
-
Customer onboarding: Set up a verification flow with the required document, biometric, and compliance checks. Define which results allow automatic approval and which require another attempt, additional evidence, or manual review. Our guides to digital onboarding and onboarding best practices cover the process in more detail.
-
Transaction and activity monitoring: Configure rules to flag suspicious transactions and account behavior. Triggers may include unusual transaction volumes, rapid movement of funds, or an account login from a jurisdiction restricted by company policy.
-
Ongoing sanctions screening: Recheck existing customers when relevant sanctions lists are updated, so newly listed individuals or entities can be identified after onboarding.
-
Ongoing PEP and adverse media screening: Schedule repeat checks based on customer risk and applicable requirements and reassess risk when relevant new information appears. See our PEP screening guide for more on ongoing monitoring.
The important part is connecting these checks to what happens next. With clear rules in place, the system can respond automatically to certain risks and route more ambiguous cases to an analyst, rather than leaving employees to figure out the next step every time.
For example, Regula IDV Platform can analyze device IDs, IP addresses, geographic patterns, and profile activity to spot suspicious behavior, such as multiple registrations from the same device or unusual location changes. You can set risk thresholds and decide what happens when they're crossed: block a suspicious device, reject a verification session, or send the case for manual review.
However, not every alert can be resolved automatically. A case management system helps analysts investigate flagged cases and review the information behind them.
For AML/PEP screening, for instance, Regula IDV Platform allows businesses to create a case automatically when a check flags a potential match. The assigned analyst reviews the flagged result alongside the customer's information to understand what triggered the alert. Based on that review, they decide whether to clear the match, request additional checks, or escalate the case. Each action is logged with the user's identity, timestamp, and reason.
Finally, the system should support actions on customer accounts. Depending on applicable rules, compliance staff may need to request additional documents, block a payment method, restrict account activity, or freeze funds.
Ideally, compliance staff can initiate these actions from the customer profile or case, either directly or through connected systems. The case history should record what was done, who authorized it, and why.
Keep an audit trail that explains compliance decisions
Suppose a sanctions alert was cleared six months ago. An auditor may want to know who reviewed it, what information they checked, and why they decided there was no match. A simple "closed" status won't answer those questions.
To make compliance decisions traceable and protect sensitive data, the system should maintain the necessary audit records and enforce access controls:
-
Role-based access control (RBAC): Administrators can assign roles to user groups and control access to sessions, workflows, and profiles, as well as permitted actions
-
Employee access logs: Every time an employee accesses a customer account, the system records who accessed it and when
-
Alert history: Every alert is documented in the customer's profile, including those eventually dismissed as false positives
-
Analysis and decisions: Analysts record their findings and explain why an alert was cleared, escalated, or led to further action
-
Customer documents: Identity documents and supporting evidence are attached to the customer account or stored in a secure, accessible repository
-
Data governance and retention: Customer records and transaction histories are kept for the periods required by applicable regulations, with appropriate access controls
Some records, such as timestamps and access logs, can be captured automatically. The reasoning behind a decision usually requires input from the analyst who handled the case.
Plan for investigations and regulator requests
The organization also needs a defined process for receiving, validating, escalating, and responding to regulatory or law-enforcement requests.
Interactions with regulators and law enforcement can go both ways. A company may need to report suspicious activity through mechanisms such as SARs or STRs. Regulators and law-enforcement agencies may also contact the company as part of an investigation, subpoena, or formal request.
Consider a law-enforcement request for information about a particular customer. The request may cover transaction history, identity documents, account activity, IP addresses, or device information. The team verifies the requester's identity and authority, checks the request's legal basis and scope, retrieves the relevant records, and obtains approval before sharing any information.
The original request, approval, documents disclosed, and response date should all be recorded. That way, the company can later establish exactly what information it shared, with whom, and on what grounds.
Companies may set up a dedicated contact page for authorities or use platforms such as Kodex to receive and manage requests.
Important: No tipping off
In many jurisdictions, anti-money laundering laws prohibit informing customers that a suspicious activity report has been filed or disclosing information that could compromise an investigation. Staff handling these cases should understand the applicable restrictions before communicating with the customer.
Security check: Verify the requester
A request bearing an agency's name does not automatically make it legitimate. Before sharing customer information, verify the requesting officer's identity and authority through an independently confirmed official channel. This helps prevent fraudulent requests designed to obtain sensitive data.
Bottom line
A compliance program can define the steps in an investigation, but it can't anticipate every situation or tell an analyst how to weigh conflicting evidence. Some decisions still depend on professional judgment and the ability to explain the reasoning behind them.
Good judgment comes with experience, and teams need opportunities to develop it. Regular training helps, as does discussing difficult cases with colleagues. Senior compliance professionals may also benefit from certifications offered by ACAMS or the International Compliance Association (ICA).
And remember the people on the other side of your checks. Some friction is unavoidable when meeting regulatory obligations and protecting the business. But every additional check should serve a purpose. A good compliance program protects the company while treating legitimate customers fairly.
Identity verification is one way to put this principle into practice. Regula helps businesses automate document and biometric checks, apply different verification flows based on risk, and integrate those results into broader compliance processes.
If you're building or reviewing an identity verification workflow as part of your compliance program, talk to our experts about the setup that fits your requirements. Or, if you'd like to discuss something from this guide, feel free to reach out to me on LinkedIn.
.webp)