Guides / Swootle Research / 2026-07-18

Compare perpetual KYC software for EU AMLR readiness by workflow fit, provider boundaries, refresh design, implementation duties and buyer questions.

Perpetual KYC software for EU AMLR workflow readiness

Perpetual KYC software is a category of workflow and control tooling for keeping customer understanding current after onboarding. The useful question is not whether a vendor can promise “continuous KYC”; it is whether the firm can define a refresh or review path, collect the right new information, connect entities and relationships, apply its configured risk logic, route human decisions, and retain the resulting context. The surrounding scheduling, event, provider and monitoring responsibilities must be made explicit.

For EU teams, this matters because Article 26 of Regulation (EU) 2024/1624 covers ongoing monitoring of business relationships and transactions, customer-information updates and event-led review. The Regulation generally applies from 10 July 2027, with the specified Article 3(3)(n) and (o) exception applying from 10 July 2029. Read the Article 26 guide for the legal mechanics and transition status.

This page is for buyers comparing the category. It explains what perpetual KYC software should and should not mean, how to test a vendor, and where a configurable workflow product such as Swootle may fit.

What the category should mean

Perpetual KYC is an operating model rather than a single product feature. A firm maintains a living understanding of the customer and relationship through an intentional combination of initial data, changed information, periodic refresh, external results, risk decisions and human review. The exact operating model depends on the firm’s services, customers, jurisdictions, risk appetite, data sources and accountable teams.

A credible solution should help a buyer answer five questions:

1. What changed, or why is this relationship being reviewed now?
2. Which customer, entity, beneficial-owner or control information is in scope?
3. What evidence or external result supports the new understanding?
4. Which risk, review or approval path applies?
5. What decision was made, by whom, with which context and next action?

That is narrower and more useful than saying a platform “continuously monitors customers”. The phrase may refer to scheduled refresh tasks, external screening alerts, transaction-monitoring alerts, relationship data changes, or a queue of manual reviews. Those are different sources and controls. A buyer should require the vendor to describe each one precisely.

Category boundaries: five adjacent capabilities

Onboarding

Onboarding establishes the initial relationship. It normally collects identity, entity, ownership, purpose, expected activity, documents and other information needed for the firm’s initial customer-due-diligence decision. Perpetual KYC starts with that context but exists to maintain or reassess it over time. A refresh should not blindly repeat every onboarding question; it should ask what the policy says is relevant to the trigger, risk level or review cycle.

Identity verification

Identity verification checks whether identity information can be verified through a method or provider. It is an input to customer due diligence, not the whole CDD record and not a perpetual-KYC operating model. A vendor may provide a workflow that requests a new identity document or routes a verification result, while the actual check is performed by an external provider. Ask what is native, what is provider-dependent and what result returns to the review record.

Screening

Screening compares people or entities against relevant lists or data sources, such as targeted financial sanctions, PEP or adverse-media sources, according to the firm’s arrangements. It can create a refresh or review event, but a screening result does not establish that all customer information is current. Nor does a workflow that stores a screening result prove that the product performs native PEP, sanctions or adverse-media monitoring. Confirm the provider, list coverage, frequency, matching logic, review process and retained result.

Transaction and activity monitoring

Transaction monitoring examines customer activity against the firm’s knowledge of the customer, business activity and risk profile. Under Article 26, this sits alongside the obligation to keep relevant customer information current. It is not interchangeable with a KYC refresh. A transaction-monitoring engine or external provider may create a case or review request; the refresh workflow may then collect context and route a decision. Decide which system owns the activity signal, investigation, escalation and handoff.

Case management

Case management organises work: ownership, queues, notes, tasks, priorities, deadlines and investigation status. It can be part of a perpetual-KYC implementation, but case management alone does not enforce the required customer questions, evidence requests, relationship model, risk path or approval. Conversely, a workflow product may support structured review without being a full investigation or enterprise case-management system. Make that boundary visible in the operating design.

Buyer evaluation matrix

Use the matrix during a demonstration. Ask the vendor to show a representative customer, an entity with related parties, a changed fact, a provider result that needs review and a human approval decision.

The buyer should ask the vendor to label every result as native, configurable, provider-dependent, an API or HTTP handoff, or out of scope. “Supported” is too vague to be an implementation decision.

A practical implementation architecture

The cleanest design separates policy, workflow, data and external execution while keeping the relationship context connected.

Policy and control definition. Start with the firm’s approved review intervals, higher-risk treatment, event types, required data, evidence standards, decision options and escalation rules. For EU AMLR planning, map the one-year maximum for higher-risk Section 4 customers and five-year maximum for other customers into the control register, while separately mapping event-led updates and transaction/activity monitoring.

Workflow and customer experience. Configure the customer-facing route with the questions, branches and document requests required for each approved path. Let the firm ask only what the review requires, but keep a reason for each request. The customer portal should make the request understandable and let operations see what is missing, supplied or returned for follow-up.

Entity and relationship model. Collect the entity, individual, ownership and control relationships that the firm needs for its service. Preserve the relationship between a new submission, the affected party and the review decision. Do not describe this as automatic resolution of every ownership chain unless a separate, confirmed capability provides it.

Provider and event interfaces. Define where identity, entity, screening and transaction-monitoring results originate. Define the event contract: subject, event type, source, timestamp, relevant result, severity, retry or failure handling, and the workflow state that should follow. A webhook or API connection is an integration design, not proof that the vendor supplies the external monitoring or provider service.

Risk and human decision layer. Use configured risk factors to route additional questions, document requests, review and approval. Keep the reviewer’s decision, comments and new context with the refresh. Where a provider result is ambiguous, the workflow should support review and escalation without presenting the provider output as the firm’s conclusion.

Records and operations. Decide how the firm will link the refresh to the relationship, distinguish old and new information, retain required evidence, manage access, resolve failed requests and produce the records needed by management or a competent authority. Confirm export scope and retention rather than assuming a vendor’s generic “audit trail” covers the complete history.

Workflow initiation, scheduling, event detection, transaction monitoring, provider selection and integrations are implementation responsibilities unless separately confirmed for the proposed deployment. This is a healthy architecture boundary: it lets the firm assign ownership rather than hiding a missing control behind a product label.

Demo questions that expose the real fit

Ask the vendor to run a complete scenario, not a collection of isolated features:

• Start with an approved corporate customer and show its related individuals, entity and control information.
• Introduce a changed beneficial-owner or control fact and show how the firm would initiate the appropriate review.
• Request only the affected evidence and explain why each question or document is included.
• Apply configured risk factors that require additional review or approval.
• Show how an external KYC, KYB or screening result is received, associated with the correct party and routed to a human.
• Show a reusable refresh workflow with the new submission, prior context and decision rationale distinguishable.
• Show how the team records a transaction-monitoring handoff without claiming that the workflow itself observes all transactions.
• Demonstrate what an operations lead, reviewer, MLRO and customer can each see.
• Export or retrieve the record and identify exactly what is and is not included.

The most revealing question is often: “Which part of this scenario is your product executing, which part is it routing, and which part must our team or another provider implement?”

Vendor red flags

Be cautious when a vendor:

• treats an annual questionnaire as proof of perpetual KYC without event handling or decision context;
• calls a customer portal “continuous monitoring” without describing the source of the event;
• presents identity verification, screening or transaction monitoring as interchangeable with CDD refresh;
• claims that one integration resolves every beneficial owner or complex ownership chain;
• implies native PEP, sanctions or adverse-media monitoring without naming the data and execution boundary;
• promises automatic enrolment or a native scheduler without showing configuration, ownership, failure handling and controls;
• calls a generic log a complete immutable audit ledger or complete export history;
• treats provider output as a final compliance decision rather than an input for review;
• cannot show how new information and reviewer decisions relate to the prior customer context;
• refuses to separate native, configurable, provider-dependent and implementation-owned functions.

These are not merely procurement objections. They are signs that the product story may be hiding who operates a control and how the firm will evidence it.

EU AMLR context

Article 26 of Regulation (EU) 2024/1624 is the relevant legal anchor for this category. It covers ongoing monitoring of the business relationship, including customer transactions; keeping relevant customer documents, data and information up to date; maximum update intervals of one year for higher-risk Section 4 customers and five years for all others; and review when circumstances change, a relevant fact becomes known or a specified legal contact obligation applies. It also contains separate targeted-financial-sanctions verification requirements.

AMLA opened a consultation on draft Article 26(5) guidelines on 3 June 2026, with a deadline of 3 September 2026. The draft consultation material addresses keeping customer information up to date and the transaction and activity monitoring framework. It is not final guidance. Buyers should therefore make the legal mapping explicit, date their assumptions, and plan a review when final guidance and competent-authority expectations are available.

Use the EU AML workflows guide to turn those requirements into an operating map. The ongoing monitoring product page describes the workflow surface that can be evaluated, while the Article 26 explainer keeps the legal and control distinctions in one place.

Where Swootle fits, with proof-safe claims

Swootle is a configurable workflow layer for collecting and reviewing structured information. It supports configurable workflows, branches, questions and document requests; a customer portal; entity and relationship collection; configured risk; human review and approval; and reusable refresh workflows that retain new submissions and decision context.

That can be useful when a firm needs to turn a defined refresh policy into consistent customer requests and review paths. For example, a team can configure a targeted relationship-change journey, request updated documents from the customer, collect the affected entity or person information, route a configured risk outcome to human review, and retain the new submission with the reviewer’s decision context.

The fit has clear limits. External KYC, KYB and screening are provider-dependent. Swootle should not be read as claiming a native scheduler, automatic enrolment, continuous-monitoring runtime, native PEP/sanctions/adverse-media monitoring, universal ownership resolution, complete immutable audit ledger or complete export history. Workflow initiation, scheduling, event sources, transaction or activity monitoring, provider execution and integrations are implementation responsibilities unless separately confirmed. Confirm each boundary in the solution design and commercial scope.

To test that fit, bring a representative file with a changed relationship, a missing document, a provider result requiring review and an approval decision to the Swootle demo.

Frequently asked questions

What is perpetual KYC software?

It is software used to operate and evidence risk-based customer refresh and review work over the life of a relationship. The category may include configurable questions, evidence requests, branches, relationship collection, risk routing and human review. It does not automatically include every scheduler, event source, provider or monitoring engine.

Is perpetual KYC the same as onboarding?

No. Onboarding establishes the initial customer relationship. Perpetual KYC maintains or reassesses the firm’s understanding as information, risk, activity or circumstances change. A good refresh is targeted to the reason for review rather than an automatic replay of every onboarding question.

Is perpetual KYC the same as screening?

No. Screening is a separate check against relevant lists or data sources. A result may start a review, but it does not prove that CDD information is current. Confirm which screening provider runs, what result returns and how a human decision is recorded.

Is perpetual KYC the same as transaction monitoring?

No. Transaction or activity monitoring assesses customer activity against the firm’s knowledge of the customer, business activity and risk profile. It may create a review or case. A perpetual-KYC workflow can collect context and route a decision, but it is not automatically the runtime observing every transaction.

What should a buyer ask about EU AMLR Article 26?

Ask how the implementation maps ongoing relationship and transaction monitoring, customer-information updates, the one-year and five-year maximum update intervals, event-led review and targeted-financial-sanctions verification. Ask who owns each trigger, provider, decision and retained record. See the Article 26 guide for the exact distinctions.

Does Swootle automatically enrol every approved customer into monitoring?

Do not assume that. Swootle supports reusable refresh workflows and can support configured collection, risk and review paths. Workflow initiation, scheduling, event sources and integrations are implementation responsibilities unless separately confirmed for a particular deployment.

Can perpetual KYC software resolve all beneficial owners?

No general product claim should be accepted without testing the data sources, jurisdictions, ownership types and exception handling. Swootle can collect and relate configured entity, ownership and control information; that is not a claim of universal ownership resolution.

Review and maintenance

Swootle Compliance Research reviewed this guide against the official EUR-Lex text, AMLA consultation page and current product-proof boundaries on 4 August 2026. Read about the team’s compliance-operations background. This editorial review is not a named legal opinion or procurement endorsement.

Disclaimer

This page is general commercial and implementation information, not legal advice, a procurement recommendation or a complete interpretation of Regulation (EU) 2024/1624. It does not constitute final AMLA guidance. Applicability and control design depend on the firm’s entity type, services, Member State, risk assessment, providers and other Union or national requirements. Confirm the current EUR-Lex Regulation, AMLA consultation status and the relevant competent-authority expectations before implementation.

This guide was materially updated on 4 August 2026. Its original publication date remains 18 July 2026.