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
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 ↗