THE INDEPENDENT PAYMENTS INTELLIGENCE PLATFORMBuilt around merchants. Not a single provider. ↗
Guide · KYC and KYB

Ongoing Merchant Monitoring

Ongoing Merchant Monitoring: Why KYC and KYB Do Not Always End at Approval The merchant that passed KYB two years ago may no longer exist in quite the same form. The legal entity may still have the same registration number. But one ultimate beneficial owner has exited. Two direct

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Ongoing Merchant Monitoring: Why KYC and KYB Do Not Always End at Approval

The merchant that passed KYB two years ago may no longer exist in quite the same form.

The legal entity may still have the same registration number. But one ultimate beneficial owner has exited. Two directors have changed. Settlement now goes to another bank account. The company sells into countries that were absent from the original application. Its product has moved from one-time purchases to subscriptions.

Nothing about that sequence necessarily means the merchant has done anything wrong.

It means something more basic:

The facts that were verified at onboarding are no longer all the facts of the current business.

That is the reason ongoing merchant monitoring exists.

KYC and KYB are not necessarily permanent certifications of an unchanging merchant. They establish and assess information at a point in a continuing relationship. When material facts change—or when a scheduled review is due—the provider may need to update, confirm, or re-verify parts of that profile.

The current FATF Recommendations make this principle explicit at the international-standard level. Recommendation 10 includes ongoing due diligence during a business relationship, and its interpretive guidance says customer-due-diligence records should be kept relevant and up to date through reviews, particularly for higher-risk customer categories. FATF standards are implemented through national frameworks rather than operating as one universal PSP rule.

For merchants, the operational principle is:

Ongoing monitoring exists because the verified merchant can change after approval. The objective is to keep the compliance record materially aligned with the business that is actually processing today.

That does not mean repeating the entire onboarding process every month, quarter, or year.

The more useful model is:

detect material change → determine what information is affected → update that information → verify what needs re-verification → reassess the relevant relationship

What is ongoing merchant monitoring?

In this KYC/KYB context, ongoing merchant monitoring is the post-approval process of keeping material information about the merchant and relevant associated persons sufficiently current, and reassessing it when required by the applicable legal, regulatory, provider, acquiring, banking, payment-method, or risk framework.

The subject is the merchant profile.

Potential elements include:

legal-entity information;

ownership and control;

UBOs;

directors or other relevant managers;

authorized representatives;

registered or operating addresses;

business activities;

products and services;

geographic footprint;

licensing status where relevant;

bank or settlement accounts; and

other information on which the continuing merchant relationship depends.

Not every change requires the same response.

A new office phone number is different from a change of control.

A typo correction is different from replacing the settlement account.

Adding a minor product variation is different from changing the fundamental business model.

The purpose of a monitoring framework is therefore not simply to detect change.

It is to determine:

Does this change affect a fact that matters to the verified merchant relationship?

Why approval is not necessarily the end of KYC or KYB

Initial onboarding answers questions using the merchant as it exists at that moment.

For example:

Which company is applying?

Who owns or controls it?

Who represents it?

What does it do?

Where does it operate?

Where will settlement go?

Approval does not freeze those answers in time.

FATF's current Recommendation 10 says financial institutions should conduct ongoing due diligence and apply due diligence to existing relationships at appropriate times based on materiality and risk. Its interpretive note separately calls for existing CDD records to be reviewed so collected information remains relevant and current.

A jurisdiction can translate that broad standard into more specific obligations. In the United Kingdom, for example, Regulation 28 of the Money Laundering Regulations requires relevant persons within its scope to conduct ongoing monitoring of business relationships and to review existing records so CDD information remains up to date. The same regulation makes the extent of the measures risk-sensitive rather than identical in every case. That is a UK legal example, not a universal rule for every merchant or PSP globally.

The distinction matters:

Initial verification asks whether the merchant profile can be established.

Ongoing monitoring asks whether that established profile remains sufficiently accurate.

Ongoing merchant monitoring is not the same as transaction monitoring

These concepts are related in financial-crime frameworks, but they are not interchangeable.

Merchant-profile monitoring asks:

Is the legal entity information still correct?

Are the same people the UBOs?

Has control changed?

Are the directors or representatives current?

Is the business still selling what it originally described?

Has the geographic footprint changed?

Is the settlement account still the same?

Have relevant licenses or regulatory circumstances changed?

Transaction monitoring asks:

What is happening in transactional activity?

Are payment patterns consistent with expectations?

Are there activities requiring further financial-crime investigation or controls?

FATF's wider concept of ongoing due diligence includes scrutiny of transactions throughout the relationship.

This article deliberately owns the merchant-profile side of the problem: keeping the verified KYB/KYC picture aligned with the merchant after onboarding.

Detailed transaction-monitoring architecture belongs in a separate AML or transaction-monitoring discussion.

Periodic review versus event-driven review

A strong ongoing-monitoring model separates two mechanisms.

Periodic review

A periodic review is a reassessment initiated according to a provider's applicable review cycle or risk methodology.

The purpose may be to ask:

"Are the facts we previously verified still correct?"

That can involve reviewing existing information, confirming it, updating changed data, and addressing verification issues that arise.

There is no defensible universal rule that says every merchant must be completely reverified every 12 months, every two years, or on another single interval.

Risk, jurisdiction, provider framework, product, business relationship, and other factors can affect review frequency.

The UK's FCA illustrated the risk-based principle in April 2026 when publishing findings from its review of firms' CDD and ongoing-due-diligence controls. It observed that stronger firms tailored CDD to customer risk and that higher-risk customers received more frequent review; it also criticized firms that failed to follow their own periodic-review policies. This is FCA supervisory guidance for relevant UK-regulated firms, not a worldwide PSP timetable.

Event-driven review

An event-driven review begins because something materially changes rather than because a calendar date arrives.

Examples can include:

ownership change;

control change;

new relevant company representative;

material business-model change;

new bank account;

legal-entity change;

address change;

new market or regulated activity;

a material change in the information or risk associated with the merchant.

Provider implementations demonstrate the distinction.

Adyen's current Business Accounts documentation describes periodic data reviews of existing legal-entity information, including associated UBOs and signatories. It also states that a data review may be required outside the scheduled period following a significant change in information or risk level. That is Adyen's documented framework for the relevant product, not a universal PSP rule.

The useful merchant question is therefore not:

"When is our next KYC?"

It is:

"What changes could make our currently verified profile stale before the next scheduled review?"

The Ongoing Merchant Monitoring Trigger Map

A merchant can organize post-approval change around six trigger families.

Trigger family

Example change

Information affected

Possible verification response

Merchant operational priority*

Likely internal owner

Ownership / control

New shareholder, changed UBO, acquisition, control change

Ownership chain, UBO/control analysis

Update structure; identify and verify newly relevant persons where required

High

Legal / compliance / corporate

Management / representation

New director, controller, representative or signatory

Relevant natural persons and authority

Update role; verify identity/authority where applicable

High

Legal / compliance

Business

New products, subscription model, material activity change

Business description, risk profile, potentially licensing/category

Explain change; provide supporting information if requested

High where material

Product / compliance / payments

Geography

Entering new customer or operating markets

Geographic profile, licensing, provider/payment-method eligibility

Update markets and reassess applicable requirements

Before launch where possible

Expansion / legal / payments

Operations

New settlement account or material address change

Bank ownership/settlement relationship or address

Verify changed account/address as applicable

High before dependent flows change

Treasury / finance / operations

Compliance / status

Expiring evidence, licensing change, relevant screening/status change

Existing verification record

Refresh affected evidence or undertake additional review

According to applicable deadline / urgency

Compliance / legal

*Operational priority is a merchant planning recommendation, not a universal legal deadline. Actual notification and verification deadlines depend on the applicable law, contract, provider, account, and circumstances.

The map highlights the central principle:

A trigger should point to the information that became stale.

It should not automatically mean:

"Start onboarding from page one."

Trigger 1: Ownership or control changes

Ownership is one of the clearest examples of a fact that can become obsolete after onboarding.

Suppose a merchant originally had:

Person A → 60%

Person B → 40%

After an investment round, acquisition, restructuring, or secondary sale, the structure could become:

Holding Company X → Merchant

with new natural persons behind Holding Company X.

The original beneficial-ownership analysis may no longer answer:

Who ultimately owns or controls this merchant today?

The appropriate response can require some combination of:

updated shareholder information;

revised ownership mapping;

evidence for new intermediate entities;

identification of new relevant natural persons;

KYC of newly relevant persons where applicable;

explanation of the transaction or restructuring; and

independent verification where available and required.

That does not mean every shareholder change necessarily produces identical verification work.

The applicable ownership/control test must still be determined under the relevant jurisdiction and provider framework. For deeper treatment, see Ultimate Beneficial Owner Requirements.

Why ownership changes are operationally important

An outdated ownership chart creates a dependency problem.

The provider may discover one ownership picture from:

the merchant;

a registry;

an external data source;

another corporate document; or

a previous verification record,

while the merchant's current structure says something else.

A legitimate corporate event can then look like an unexplained discrepancy until the relationship is reconciled.

The merchant-controlled solution is not to wait for the next review.

Maintain a current ownership map internally and know which payment and banking relationships require notification when it changes.

Trigger 2: Directors, controllers and representatives change

The merchant's people can change even when its owners do not.

A founder can leave the board.

A professional CEO can replace the founder.

A director can resign.

An authorized representative can move to another role.

These changes affect management or representation, which is distinct from beneficial ownership.

The merchant should therefore maintain separate records for:

ownership/control

and

management/representation

rather than assuming an unchanged cap table means the KYC/KYB profile is unchanged.

A new director does not automatically become a UBO.

A new UBO does not automatically become a director.

A new employee completing provider administration is not automatically authorized to bind the business.

For the role-specific verification logic, see Director Verification and KYC Explained.

Trigger 3: The business model changes

A merchant can remain the same company, with the same owners, at the same address—and still become materially different from the business originally approved.

Consider changes such as:

one-time ecommerce → recurring subscriptions

software licensing → marketplace

physical goods → digital services

domestic sales → substantial international sales

direct sales → third-party sellers

immediate delivery → substantial future delivery

Whether a particular change triggers additional provider review depends on the relationship.

But the logic is straightforward:

The provider's understanding of the merchant's activity is part of the profile it originally assessed.

If that activity changes materially, the existing description may no longer be adequate.

The operational lesson is important:

Do not assume that "same legal entity" means "same verified merchant."

Trigger 4: Geography changes

New-market expansion can change several pieces of the merchant profile at once.

A new geography can affect:

customer location;

operating footprint;

required licenses;

product legality or regulation;

acquiring configuration;

payment-method availability;

settlement;

sanctions exposure;

other provider-specific eligibility or compliance requirements.

The merchant should therefore distinguish:

the provider supports payments in Country X

from:

this merchant's expansion into Country X fits the currently approved relationship

Those are not necessarily the same question.

Before launching materially new markets, the merchant's payments/compliance owner should ask:

Is this geography already reflected in the provider profile?

Does the merchant's activity there require a new entity, license, registration, or arrangement?

Does the payment provider need to approve or configure anything?

Does the new geography change the ownership, banking, business, or risk information already supplied?

The article KYC Requirements by Country should own detailed jurisdiction-by-jurisdiction verification requirements.

Trigger 5: The settlement bank account changes

A settlement account is not merely a routing destination.

Verification may involve establishing:

the account;

the account holder;

the relationship between the account and merchant;

and whether it can be used for the intended settlement arrangement.

Changing the account can therefore create a new verification event.

Checkout.com's current documentation provides a provider-specific example. It requires defined verification information when adding or updating a settlement bank account and calls for justification where the bank-account holder is a different entity. It also requires such account-change requests to come through an authorized or delegated signatory under the documented process.

Stripe's current Connect documentation likewise illustrates the broader principle that updating previously verified information can cause that information to be reviewed again. The precise fields, deadlines, and consequences described there apply to relevant Stripe Connect configurations rather than merchant accounts universally.

For the underlying ownership and settlement question, see Bank Account Verification.

Treat bank changes as controlled changes

A merchant planning to replace its settlement account should not treat the change as a last-minute treasury update.

Internally record:

current account;

intended account;

account holder;

entity relationship;

currency;

settlement purpose;

requested effective date;

verification evidence;

provider approval/status where required.

That makes the bank change a managed dependency rather than an unexpected payout blocker.

Trigger 6: Previously verified evidence becomes stale or requirements change

Sometimes the merchant itself has not materially changed, but the verification environment has.

Possible reasons include:

evidence no longer being current for the relevant purpose;

new verification information being required;

a provider changing its KYC/KYB implementation;

a regulatory or partner requirement changing;

a previous verification issue becoming relevant again;

a scheduled provider review.

Stripe's current Connect documentation is a concrete provider example: Stripe states that verification requirements can change following developments involving regulators, card networks, or other financial institutions, and its platform tooling exposes future or current verification requirements that affected connected accounts need to resolve.

This does not mean merchants should continually upload replacement documents without being asked.

It means previously complete verification is not necessarily immutable.

Re-verification is not necessarily complete re-onboarding

This distinction is central.

Initial onboarding asks:

Can this merchant relationship be established?

Re-verification asks:

Has a previously established fact changed, become stale, or become insufficient under the current requirements?

Those questions can produce very different scopes.

If a merchant changes its bank account, the immediate verification problem may concern the new bank relationship.

If a new UBO enters the ownership chain, the change may require ownership analysis and KYC of the newly relevant person.

If the legal entity itself changes, the consequences can be broader.

If nothing material changed but a periodic review is due, the merchant may simply need to confirm existing information and update specific fields.

Adyen's current data-review process makes the distinction particularly visible: existing legal-entity, UBO, and signatory data is reviewed; if there are no verification errors the user can confirm the information, while changed data can be updated and verified again. Adyen also documents that legal-entity updates such as ownership or address changes can cause verification checks to run again. These are product-specific Adyen processes, but they show why a refresh need not be conceptually identical to a brand-new onboarding.

The correct merchant question is:

What fact changed, and which verification dependency does that change reopen?

A practical change-impact model

Before notifying or updating a provider, classify the change.

Level 1 — Administrative correction

Examples might include a non-material contact correction or typo.

Question: Does this alter any verified legal, ownership, authority, banking, geographic, or business fact?

If not, the change may be limited.

Level 2 — Verified-field change

Examples:

registered address;

director;

representative;

settlement account.

Question: Which specific verified relationship now needs to be updated?

Level 3 — Structural change

Examples:

new UBO;

change of control;

new parent company;

legal-entity transformation.

Question: Does the ownership/control or legal-entity analysis need to be rebuilt?

Level 4 — Business/risk change

Examples:

fundamentally different product;

marketplace launch;

new regulated activity;

material geographic expansion.

Question: Does the provider still understand and support the business it is processing for?

This four-level model is conceptual, not an industry-standard risk classification.

Its purpose is to prevent the merchant from treating every change identically.

Merchant-declared information versus independently verified information

Ongoing monitoring can rely on different evidence layers.

Merchant-declared update

The merchant reports:

"Director A has resigned and Director B has been appointed."

That is information.

Documentary support

The merchant supplies accepted corporate evidence showing the change.

That is evidence.

Independent information

Where available and appropriate, the provider may compare the change against:

official registries;

reliable electronic data;

banking information;

screening sources;

other authoritative or accepted data.

That is independent corroboration.

Verification result

The provider determines whether the updated fact has been sufficiently established for the relevant purpose.

That is verification.

Do not collapse these stages into one.

Reported ≠ documented ≠ independently checked ≠ verified.

Why legitimate changes still create mismatches

A mismatch during ongoing KYB does not automatically mean the merchant provided false information.

Real companies change faster than every data source updates.

Legitimate examples can include:

a newly appointed director not yet reflected everywhere;

a recent office move;

a bank using an abbreviated legal name;

a completed acquisition with registry updates still processing;

transliteration differences;

a group treasury account;

a newly issued license;

an internal system still carrying old ownership data.

The monitoring problem is:

Which version reflects the current legal and commercial reality?

A merchant can reduce rework by keeping:

effective date;

old value;

new value;

business reason;

supporting evidence;

affected providers;

notification status;

verification status

for every material change.

This creates an auditable merchant change register.

Build a merchant change register

For sophisticated payment operations, ongoing KYC/KYB should not live solely in compliance inboxes.

Maintain a structured register:

Field

Purpose

Change ID

Unique internal reference

Effective date

When the underlying fact actually changed

Change category

Ownership, director, business, geography, bank, address, etc.

Old value

Previous verified state

New value

Current state

Legal entity affected

Prevents group-company confusion

Provider relationships affected

Which PSPs/acquirers/banks may need the update

Internal owner

Who supplies the evidence

Evidence available

What supports the change

Provider notified

Yes/no/date

Re-verification required

Known, no, or awaiting provider determination

Current status

Open / under review / resolved

Completion evidence

What proves the change is closed

This is not a regulatory form.

It is an operational control for avoiding stale merchant profiles.

Who should own each trigger?

Ongoing merchant monitoring fails easily when every department assumes someone else will tell the PSP.

A useful internal ownership model is:

Corporate/legal

Own changes involving:

legal entity;

corporate structure;

shareholders;

directors;

control;

material corporate actions.

Compliance

Own:

determining which compliance relationships may be affected;

coordinating KYC/KYB evidence;

screening-related changes;

licensing/compliance status where relevant.

Treasury/finance

Own:

settlement bank changes;

account ownership evidence;

finance-related provider updates.

Payments operations

Own:

provider inventory;

status tracking;

notification routing;

ensuring open provider dependencies are closed.

Product/commercial/expansion

Own early notification internally when:

products change;

business models change;

new markets launch;

transaction models materially change.

The operating principle should be:

The team making the business change should trigger the compliance-impact assessment before the payments team discovers it afterward.

Periodic review should not become blind document recollection

The editorial danger in ongoing KYB is to assume that "review" means:

ask for every onboarding document again.

That is not the principle contained in FATF's risk-based framework. FATF calls for records to remain relevant and current and for due diligence measures to be applied based on risk; it does not prescribe one global recurring document pack for every customer relationship.

The FCA's 2026 CDD review likewise emphasizes risk-sensitive approaches and notes more frequent review for higher-risk customers rather than describing one identical review cycle for all customers.

A better periodic-review sequence is:

What do we currently believe?

↓

What has changed?

↓

Which evidence remains sufficient?

↓

Which information needs refreshing?

↓

Which discrepancies need resolution?

↓

Does the current risk/profile assessment still make sense?

That focuses effort where the information has actually changed or where current requirements justify an update.

Event-driven monitoring should happen near the event

Periodic review is weakest when merchants rely on it as the only way to discover change.

Imagine a merchant changes control in January but its next provider review does not occur until November.

Waiting for the periodic review would leave the provider profile stale for months.

That is why merchant operations should establish internal change triggers independently of whatever periodic schedule a provider uses.

When an event is planned, ask before implementation where feasible:

Does this change affect any payment provider, acquirer, bank, or payment method?

That is particularly valuable for:

mergers;

acquisitions;

major investments;

new entities;

new bank accounts;

market launches;

regulated product launches;

material changes to the payment flow.

The merchant may not control how quickly an external party completes its review.

It can control whether the external party first hears about the change after it has already become a production problem.

Merchant profile maintenance is part of the continuing relationship, not merely the application.

What can happen when updated information cannot be verified?

There is no single universal outcome.

Depending on the provider, issue, account, and applicable framework, an unresolved change may lead to:

another information request;

re-verification;

a review of affected capabilities;

restriction of a particular function;

escalation;

changed conditions;

or, in some circumstances, suspension or termination.

Provider documentation shows why merchants should treat verification deadlines seriously but not generalize one provider's mechanics.

Adyen's current periodic-review documentation states that verification issues must be resolved and the reviewed information confirmed; unresolved reviews can ultimately affect applicable capabilities under that product framework.

Stripe's Connect documentation similarly describes deadlines for changed verification requirements and potential capability impacts when requirements remain unresolved.

The merchant objective should therefore be:

resolve the changed fact before the unresolved verification becomes an operational dependency.

Who controls an ongoing-monitoring delay?

A reopened KYC/KYB issue can involve three kinds of elapsed time.

Merchant-controlled

Examples:

nobody internally reported the ownership change;

legal has not supplied the updated structure;

finance has not supplied bank evidence;

an old director remains in the provider profile;

the merchant has not explained the business change;

the provider request sits unanswered.

Provider-controlled

Examples:

review queue;

internal compliance assessment;

manual verification;

provider handoff;

approval decision.

Externally controlled

Examples:

registry update;

government documentation;

bank confirmation;

acquiring or partner review;

other authoritative-source dependencies.

Do not label the entire period:

"PSP compliance delay."

Ask:

What changed?

What fact is still unresolved?

Who owns the next action?

Metrics for ongoing KYB operations

Merchants managing several PSPs, entities, or markets can measure the process without inventing industry benchmarks.

Change-to-notification time

Provider notification timestamp − internal effective/change-awareness timestamp

Define which starting point is used.

Change-to-verification-completion time

Affected verification closed − change notification

This should be separated by owner where possible.

Open material changes

Number of material profile changes that have not yet been closed across applicable provider relationships.

Provider update coverage

Affected provider relationships updated ÷ provider relationships identified as affected

Re-verification cycles

Number of evidence/clarification rounds required for a particular change.

Stale-profile exceptions

Number of instances where the business discovers that a provider's profile contains materially outdated merchant information.

No universal acceptable value should be invented for these metrics.

Their purpose is internal control.

A merchant monitoring operating model

The entire process can be reduced to six questions.

What changed?

Do not start with documents.

Start with the underlying fact.

Which merchant entity changed?

Do not confuse a parent-company event with a subsidiary event.

Which existing verified information is affected?

Ownership?

Director?

Address?

Bank?

Business activity?

Geography?

Which external relationships depend on that information?

PSP?

Acquirer?

Bank?

Payment method?

Other partner?

What needs to be updated or re-verified?

Follow the applicable provider or legal requirement rather than inventing an internal document checklist.

What proves the change is closed?

A notification email is not necessarily completion.

Completion may mean:

provider record updated;

verification passed;

bank approved;

ownership review closed;

relevant payment functionality confirmed;

another explicit provider status.

This turns ongoing compliance into a controlled change-management process.

FAQ: Ongoing merchant monitoring

Does KYC or KYB end once a merchant is approved?

Not necessarily.

FATF's current customer-due-diligence standard includes ongoing due diligence during established relationships and calls for CDD records to remain relevant and up to date. National implementation and provider requirements vary.

What is a KYB refresh?

"KYB refresh" is commonly used operationally for a review or update of previously collected business-verification information.

The scope can vary. A review may involve confirming existing information, updating changed facts, resolving new requirements, or re-verifying specific relationships. It should not automatically be interpreted as a complete new onboarding.

How often does periodic KYC review happen?

There is no universal interval that should be stated for every merchant.

Frequency can depend on jurisdiction, regulated context, provider policy, risk, and the merchant relationship. FATF uses a risk-based framework, while the FCA's 2026 supervisory findings describe more frequent review for higher-risk customers rather than one interval for everyone.

What can trigger merchant re-verification?

Potential triggers can include changes to ownership/control, relevant directors or representatives, legal-entity information, bank accounts, business activity, geography, or other material profile information.

Provider workflows differ. Adyen's current documentation explicitly distinguishes scheduled data reviews from reviews that may occur following significant changes in information or risk.

Does changing a UBO mean the merchant has to onboard again?

Not automatically.

A new UBO can reopen ownership/control analysis and KYC of relevant natural persons, but whether anything broader must be repeated depends on the provider, jurisdiction, merchant structure, and nature of the change.

See Ultimate Beneficial Owner Requirements for the dedicated ownership analysis.

Does changing directors trigger new KYC?

It can trigger an update or identity/role verification depending on the applicable provider and jurisdiction.

A director change and a UBO change are not equivalent. See Director Verification for the distinction.

Why does changing a bank account require verification?

Because the provider may need to establish the new account, its ownership, and its relationship to the merchant before using it for settlement.

Checkout.com's current merchant documentation provides one provider-specific example of bank-account-change verification and additional explanation where the account holder differs from the entity.

See Bank Account Verification for the complete explanation.

Is ongoing merchant monitoring the same as transaction monitoring?

No.

Merchant-profile monitoring is concerned with whether verified information about the entity, ownership, people, business, geography, banking relationship, and related attributes remains accurate.

Transaction monitoring focuses on transactional behavior. FATF's wider ongoing-due-diligence concept can encompass both, but they are distinct operational disciplines.

Should merchants wait for the PSP to ask before reporting changes?

Not where the applicable agreement, law, or provider procedure requires the merchant to notify the provider.

Merchants should check the requirements governing their actual provider relationship rather than relying on a universal rule.

The merchant profile is a living record

The mistake is to think of KYB approval as a certificate attached permanently to a company.

It is more useful to think of it as a verified model of the merchant relationship.

That model might contain:

Entity

→ who the business is

Ownership

→ who ultimately owns or controls it

Management and representation

→ which relevant people manage or act for it

Business

→ what it does

Geography

→ where the relevant activity occurs

Banking

→ where settlement goes

Approval establishes enough of that model for the applicable relationship at that time.

Ongoing merchant monitoring asks whether the model still describes reality.

When ownership changes, update ownership.

When a relevant director changes, update the management relationship.

When the bank changes, establish the new bank relationship.

When the business materially changes, explain the new business.

When nothing material has changed but a legitimate periodic review occurs, confirm what remains accurate and refresh what genuinely needs updating.

That is different from treating every merchant as though it must endlessly repeat its original onboarding.

The central operating question is:

Which merchant fact changed, which existing verification does that change affect, and what must be updated or re-verified so the provider's compliance record again describes the business that actually exists?

That is the purpose of ongoing merchant monitoring.

Disclaimer: This article provides general information and does not constitute legal, regulatory, compliance, tax, accounting, or financial advice. KYC and KYB requirements vary by jurisdiction, regulated activity, provider, financial institution, merchant structure, and risk profile. Merchants should verify current requirements with qualified advisers, relevant authorities, and their payment providers or acquirers.

🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

A. Brief interpretation — not article copy

Element

Interpretation

Article-owned question

Why does merchant verification sometimes continue after approval, and which post-approval changes can justify an update or re-verification?

Verification subject

The merchant profile as it exists now: entity, ownership/control, relevant people, business activity, geography, address, banking/settlement relationship, and other material verified information

Verification objective

Keep the provider's material understanding of the merchant sufficiently accurate and current for the continuing relationship

Key distinction

Ongoing merchant-profile monitoring is not the same as transaction monitoring; re-verification is not automatically complete re-onboarding

Editorial position

Monitoring should focus on meaningful changes and risk rather than indiscriminately repeating every onboarding step

Unique evidence anchor

A merchant approved two years ago may now have different owners, directors, bank accounts, markets, and products; the original KYB profile can therefore cease to describe the actual business

Final merchant decision

Determine which changes are material to the verified merchant relationship, who must report them, and which affected facts need to be re-established

B. COMPLETE PUBLICATION-READY ARTICLE

C. ORIGINAL ARTICLE ASSET — NOT ARTICLE COPY

Ongoing Merchant Monitoring Trigger Map

For the production visual, I recommend a central Verified Merchant Profile surrounded by six change triggers:

OWNERSHIP / CONTROL

New shareholder → new UBO → control change

MANAGEMENT / AUTHORITY

New director → controller → representative/signatory

BUSINESS

New product → business-model change → material profile change

GEOGRAPHY

New market → new operating footprint → new applicable requirements

OPERATIONS

New bank account → new address

COMPLIANCE / STATUS

Evidence refresh → relevant screening/status change → regulatory/license change

Every arrow then feeds the same four-step response:

What information changed?

→ What verification is affected?

→ Who owns the update?

→ What proves closure?

The visual should place Periodic Review as a circular outer ring and Event-Driven Review as arrows entering from each change trigger. That makes the distinction immediately understandable.

A separate box should state:

Re-verification ≠ automatic full re-onboarding

D. SEO PACKAGE — NOT ARTICLE COPY

H1: Ongoing Merchant Monitoring: Why KYC and KYB Do Not Always End at Approval

Meta description: Learn why merchant KYC and KYB can continue after approval, which ownership, director, bank, business, and market changes can trigger re-verification, and how periodic reviews differ from event-driven monitoring.

URL slug: /kyc-kyb/ongoing-merchant-monitoring/

Secondary keywords: ongoing KYC monitoring, ongoing KYB monitoring, merchant reverification, periodic KYC review, merchant compliance monitoring, merchant onboarding monitoring, KYB refresh, merchant profile monitoring

Suggested excerpt:

Merchant approval is based on a set of verified facts—but businesses change. New owners, directors, settlement accounts, markets, and business models can make the original KYB profile obsolete. Ongoing merchant monitoring keeps the provider's material understanding of the merchant aligned with the business that actually exists.

Suggested internal links

Use KYC Explained where the article introduces natural-person re-verification.

Use KYB Explained where it introduces the merchant profile as a set of entity and relationship facts.

Use Ultimate Beneficial Owner Requirements from the ownership/change-of-control trigger instead of reproducing UBO tests.

Use Bank Account Verification from the settlement-account trigger.

A contextual link to Director Verification is also worthwhile even though it was not one of the brief's primary targets, because it prevents this article from recreating the director-versus-owner explanation.

Structured-data recommendation

Use Article schema.

Use FAQPage only if the FAQs remain visible on-page and the site's current schema implementation supports it.

No structured-data field should imply a universal periodic-review timetable.

Supporting visual

Ongoing Merchant Monitoring Trigger Map

Visual architecture:

Verified merchant profile at center.

Around it:

Ownership/control

Management/representation

Business

Geography

Operations

Compliance/status

Two monitoring mechanisms surround those:

Periodic review

and

Event-driven review

All change paths lead to:

Update → targeted re-verification → profile/risk reassessment → closure

Recommended image alt text

“Ongoing Merchant Monitoring Trigger Map showing ownership, director, business, geography, bank-account and compliance changes that can trigger profile updates or re-verification after merchant approval.”

E. SOURCE AND VERIFICATION PLAN — NOT ARTICLE COPY

Current primary sources used

FATF Recommendations, current through June 2026. This is the article's main international conceptual anchor. Recommendation 10 includes ongoing due diligence during business relationships and its interpretive note calls for CDD information to remain relevant and current, particularly for higher-risk customers. FATF is a standard setter; national implementation must still be checked.

UK Money Laundering Regulations 2017, current point-in-time version June 30, 2026. Regulation 28 provides a jurisdiction-specific primary-law example of ongoing monitoring and keeping CDD information up to date, while requiring risk-sensitive application. This should remain labeled as UK law.

FCA — CDD processes and controls findings, April 8, 2026. Useful current supervisory evidence for risk-sensitive periodic review and the operational problem of firms failing to follow their own review policies. It should not be converted into a worldwide review-frequency standard.

Adyen — Periodic data reviews. Strong provider-specific evidence for the article's periodic-versus-event-driven distinction. Adyen documents scheduled reviews of legal-entity and associated UBO/signatory data and states that significant changes to information or risk can cause a review outside the scheduled period.

Adyen — Manage legal entities. Supports the narrower statement that changes such as address or ownership can cause verification checks to run again within the documented Adyen product framework.

Stripe Connect — Handle verification updates / Update verified user information. Useful provider-specific evidence that post-onboarding requirements can change and that changes to previously verified information may require additional verification. Keep the Connect scope explicit.

Checkout.com — Update company ownership/location and bank-account details. Supports the concrete examples that ownership/location information can be updated post-onboarding and that a changed settlement account can require fresh verification evidence.

Claims requiring re-verification immediately before publication

Recheck:

the current FATF Recommendations revision date and Recommendation 10 language;

the current UK Regulation 28 text if the UK example remains;

the FCA's current CDD/ongoing-due-diligence supervisory materials;

Adyen's periodic data-review rules and significant-change language;

Stripe's Connect verification-update framework;

Checkout.com's ownership and bank-change processes;

No provider-specific review cadence should be generalized.

Jurisdiction-specific checks

The UK Money Laundering Regulations example must remain expressly UK-specific.

Do not infer from UK law that every payment provider worldwide has:

the same review cadence;

identical event triggers;

identical documentation;

identical notification rules; or

identical consequences.

If country-specific examples are later added, verify the applicable statute/regulation, regulated entity, effective date and merchant relationship individually.

Provider-policy checks

Keep each example within its documented product scope:

Adyen periodic data-review terminology belongs to the cited Adyen product.

Stripe examples are Connect-specific.

Checkout.com procedures are its current merchant/account-management processes.

Confirm:

whether the currently published notification language reflects operational practice for the intended merchant audience;

how merchant ownership/control changes are handled in practice;

whether director changes have a defined update workflow;

whether bank-account changes initiate specific re-verification;

whether "periodically update" in the underwriting section should be described publicly as periodic merchant review or kept narrower;

whether the current three-day notification provision for specified events should be surfaced in the published article.

F. HUMAN REVIEW RECOMMENDATION — NOT ARTICLE COPY

Recommended author profile: Senior KYC/KYB or merchant compliance operator with experience managing merchant changes after initial approval.

Primary compliance reviewer: AML/KYB specialist who can confirm the boundary between ongoing customer due diligence, merchant-profile maintenance, screening, and transaction monitoring.

Payments operations reviewer: Head of Payments or merchant operations lead capable of validating the change-register and trigger-map workflow across multiple PSPs.

Treasury/banking specialist: Useful for reviewing the settlement-account-change section and ensuring bank-account verification is not confused with settlement architecture.

Regional specialist: Recommended only if country-specific ongoing-review rules are added.

Recommended publication field: Include a visible Last reviewed date. Ongoing KYC/KYB rules, provider workflows, contractual terms, and verification processes are all changeable.

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗
EXPLORE PAYMENT INTELLIGENCE