Merchant risk assessment process flowchart (profile to monitoring)
Merchant risk assessment template for profile data, policy-based due diligence, fraud, dispute, financial and operational analysis, tiering, controls, decisions and review.
What the merchant risk assessment process flowchart (profile to monitoring) process is
A merchant risk assessment may begin during merchant onboarding, at a scheduled review, or after a material event changes what the organization knows about the relationship. Merchant Operations opens one case and records the trigger. The merchant or account owner supplies current information about the business model, ownership, products, geographies and sales channels, because a score built on stale facts can be precise and still be wrong. A completeness gate returns missing or outdated data for correction. Compliance then performs the due diligence required by the internal risk program, including KYC or KYB checks where applicable. The chart does not define universal requirements; evidence depth and unresolved-concern handling depend on the merchant facts, internal policy and applicable obligations.
Fraud / Disputes examines misuse, fraud patterns and dispute exposure; Credit / Underwriting looks at financial capacity and potential loss; Merchant Operations covers operational, product and integration risk. Risk Governance tests the controls already in operation against those findings. A gap does not return as a proposal for approval: the responsible owner implements the mitigation, limit or reserve condition, supplies evidence, and sends it back for effectiveness testing. Tiering follows that test. The disposition then distinguishes approval with effective controls, enhanced review, restriction and decline. Enhanced review returns for a fresh decision, restriction conditions must be implemented before monitoring begins, and a recorded decline can terminate the relationship.
Approval or restriction becomes operational through monitoring rather than sitting in a case file. Signals, thresholds, ownership and review cadence are documented and approved, then handed to merchant monitoring. A scheduled risk and control review either confirms the profile remains current or sends changed facts back through assessment. Merchant onboarding uses the initial result to configure the relationship, while exceptions and reconciliation findings can later alter financial, operational or fraud risk. Replace the placeholders with the organization's own policy, authorities and rationale; the diagram supplies structure, not a prescribed scoring model.
What this flowchart covers
In this template
- Six stages from trigger and profile intake through due diligence, risk analysis, disposition, monitoring-plan approval, and scheduled review
- Current business model, ownership, product, geography and channel data, with a return loop for incomplete or stale information
- Policy-based due diligence plus separate fraud, dispute, financial, operational, product and integration risk assessments
- Implementation evidence and effectiveness testing for mitigations, limits or reserves before tiering or approval
- Separate approve, enhanced-review, restrict and decline routes, with restrictions implemented before monitoring and declines allowed to terminate
- Monitoring signals and cadence, plan approval, handoff to merchant monitoring, and reassessment when the profile or control need changes
When to use this template
- Merchant onboarding needs a defined assessment that explains how profile facts become approval conditions rather than a single unexplained risk score
- Periodic reviews repeat data collection but do not distinguish changed merchant facts from unchanged controls and monitoring evidence
- Fraud, dispute, credit and operational teams assess the same merchant independently and no owner reconciles their conclusions
- Higher-risk cases are escalated informally without a documented enhanced-review route, decision authority or final disposition
- Payment exceptions, reconciliation differences or monitoring alerts reveal a material change that should reopen the merchant risk profile
How it works
Define assessment triggers and current-data rules
List initial onboarding, periodic review, product expansion, ownership change, unusual activity, material dispute or loss, operational incident and other approved triggers. For each profile field, state how current it must be and which source can support it. A review should refresh facts that matter to the decision rather than simply copying the last assessment date forward.
Map due diligence to the risk program
Document which KYC, KYB, ownership, business-purpose or other checks apply to each relationship and who can resolve a discrepancy. Include the route for enhanced evidence and the authority to stop an assessment when concerns cannot be resolved. Requirements vary, so have the responsible compliance and risk owners approve the method instead of importing generic thresholds.
Separate risk dimensions and evidence
Define the evidence used for fraud and dispute exposure, financial loss, operational resilience, product use, geography, channels and integration. Name one owner for each analysis and one owner who reconciles overlap. When a gap appears, record implementation and test evidence separately from the proposed mitigation so reviewers can tell what is operating, what worked and what still needs action.
Write tier, control and disposition authority
Replace the tier placeholder with internally approved criteria and specify who may approve, restrict or decline. State what qualifies for enhanced review and what evidence must return to the decision. Define restriction conditions as work to implement and monitor, not as another name for rejection; reserve a terminal path for a decline made under the relevant authority.
Turn the assessment into monitoring
For each material risk, choose an observable signal, data owner, threshold or review rule, response owner and cadence. Have the plan approved and handed to merchant monitoring with open conditions. Feed material payment exceptions, reconciliation findings and behavior changes back into the profile, and set the next scheduled review even when no alert occurs.
Frequently asked questions
What information belongs in a merchant risk assessment?
The assessment should use current business model, ownership, products, geographies, channels, expected activity and financial information, together with due diligence results and evidence about fraud, disputes, operational capability and controls. The relevant fields and evidence depth vary by product, relationship, internal policy and applicable obligations.
How should a merchant risk tier be assigned?
Use an internally approved method with defined inputs, evidence, weighting or judgment rules, decision authority and a recorded rationale. Test controls that have actually been implemented before assigning the tier; a planned mitigation is not effectiveness evidence. This template provides no score or threshold because a generic number would not reflect the organization's products, exposure, risk appetite or obligations.
What is the difference between enhanced review, restriction and decline?
Enhanced review leaves the decision open while additional evidence, specialist analysis or senior challenge is obtained. A restriction permits only a bounded relationship: its conditions must be implemented, evidenced and passed into monitoring and review. A decline refuses the relationship and may terminate the case. Separate routes keep an unresolved review or unimplemented restriction from being reported as an approval.
How does merchant risk assessment connect to monitoring?
The assessment identifies expected activity, material risks, approved controls and the conditions that would change the decision. The monitoring plan translates those findings into signals, thresholds, owners and review cadence. Monitoring alerts, payment exceptions, dispute trends and reconciliation findings then provide evidence for scheduled or event-driven reassessment.
Where this process fits
In most operations this process follows Merchant onboarding process flowchart (application to go-live) and hands off to Payment API integration process flowchart template.
It is one step in Merchant onboarding and risk.
Step 1: Merchant onboarding process flowchart (application to go-live)
Merchant onboarding process template for application intake, policy-based KYB and due diligence, risk decisions, account setup, integration testing, go-live and monitoring handoff.
Step 2: Merchant risk assessment process flowchart (profile to monitoring) You are here
Merchant risk assessment template for profile data, policy-based due diligence, fraud, dispute, financial and operational analysis, tiering, controls, decisions and review.
Step 3: Payment API integration process flowchart template
Payment API integration template for use cases, environments, access, security design, build, contract and exception testing, readiness, controlled launch, monitoring and support.
Step 4: Merchant monitoring process flowchart (signals to risk feedback)