Risk Decisioning Explained: Allow, Step Up, Review or Block

Why single pass/fail checks break down

Most onboarding stacks start as a list of independent checks: verify the document, run a sanctions screen, validate the email, check the IP. Each returns pass or fail, and someone wires them together with "if any check fails, reject". That design has two predictable problems, and they pull in opposite directions.

It rejects good customers. A genuine customer travelling abroad on hotel wifi may trigger an IP flag. Someone with a new mobile number may fail a phone check. A person who recently moved may not match an address database. None of these facts alone says the person is lying, yet a pass/fail chain treats each as grounds to decline.

It lets coordinated risk through. Every individual check can pass while the combination is suspicious. Consider an applicant whose document looks valid, whose email is real but created very recently, whose phone is a low-cost virtual number, and whose device has been seen on several other applications. Each signal sits inside tolerance. Together they describe a profile you would want a person to look at.

There is a third problem: pass/fail has only two outputs. Real onboarding decisions need more than "yes" and "no". Sometimes the right answer is "yes, once you prove one more thing" or "we are not sure, a trained person should decide". Risk decisioning adds those outcomes and the logic that picks between them.

What a decision layer does

A decision layer sits after the individual checks. It receives their results as inputs, combines them under rules you control, and returns a single outcome with the reasons behind it. The checks themselves (document authentication, biometric and liveness checks, eIDV database checks, AML screening, address, email and phone validation, IP and device intelligence) stay specialised. The decision layer is the only place where "what do we do about this customer" is answered.

That separation matters operationally. When a check changes, or you add a new one, you adjust how its result is weighed rather than rewriting your onboarding code. It also means the same customer record leads to the same outcome every time, which is the starting point for consistency and for explaining decisions later. For ScreenlyyID's view of this, see the decisioning platform page and the fraud detection and compliance product page.

The four outcomes and when each applies

The outcomes are defined by what happens to the customer next, not by how risky the score looks. Keep each definition operational so everyone on the team reads it the same way.

Two points are easy to miss. First, step up and review are different. Step up asks the customer to resolve the doubt; review asks your team to. If you send everything uncertain to review, the queue grows and customers wait. If you send everything uncertain to step up, you add friction to people who may have done nothing unusual. Second, block should be rare and well-evidenced. A decline carries consequences for the customer, so the record should show clearly why it happened.

Hard rules, weighted signals and overrides

Not every signal should be "weighed". A sound decision layer uses three kinds of logic and keeps them distinct.

Hard rules

These are conditions where the outcome does not depend on anything else. A confirmed sanctions match, for example, is not a point on a scale to be offset by a good selfie. The business policy decides what happens (typically a block or a mandatory review before anything proceeds), and that policy should be written as a rule. Likewise, a document that is clearly forged or a liveness failure with strong evidence of spoofing may be a direct route to decline under your policy.

Weighted signals

Most signals are indications, not proof. IP location mismatches, recently created email addresses, virtual phone numbers, device reuse across applications, address match quality and document quality all raise or lower the likelihood of a problem without settling it. These are the inputs you weigh together. Weighting reflects two things: how strongly the signal has predicted real problems for your business, and how often it fires on genuine customers.

Overrides and exceptions

Some segments need different handling: a higher-risk product, a particular customer type, a jurisdiction where your policy is stricter. Overrides let a rule change the outcome for those cases without distorting the weighting for everyone else. Keep them few and documented. A long list of exceptions is a sign the base logic needs rework.

How signals are weighted

There is no universal formula, and any vendor quoting one set of numbers for all businesses is simplifying. Some general principles hold across most programmes.

• Weight by evidence quality. A verified biometric match against an authenticated document is stronger evidence of identity than a single database hit. A signal that is hard to fake deserves more influence than one that is easy to fake.
• Weight by independence. Two signals derived from the same underlying data are not two pieces of evidence. If email and phone risk both lean on the same recently-created-account behaviour, counting both fully overstates the risk. Agreement between independent sources carries more information.
• Weight by context. The same signal means different things for different products. A mismatch between billing country and IP country matters differently for a travel purchase than for a domestic bank account. Weights should be able to vary by product or journey.
• Treat missing data as its own state. A phone lookup that returned nothing is not the same as a phone that looked risky. Decide deliberately whether "unknown" is neutral, mildly negative or a trigger for step up, and apply it consistently.
• Look at combinations, not only sums. Some patterns only matter together, such as a new device plus a changed email plus a new payment instrument. Rules that detect combinations catch what a simple additive score misses.

How email and phone signals are blended into a risk read is covered in the Email and Phone Risk Scoring Explained article, so this page does not repeat it. Here the point is that those outputs are one input family among several.

How thresholds are set

Thresholds are the cut-offs that turn a combined risk read into an outcome. Setting them is a business decision supported by data, not a technical constant.

1. Start from risk appetite and policy. Decide what the business will and will not accept per product: what loss level is tolerable, what regulatory obligations apply, how much friction customers will tolerate. The risk-based approach is a core idea in the standards published by the FATF: controls should be proportionate to the risk, which is why one rigid rule for all customers is rarely the right design.
2. Define bands, not a single line. A single cut-off gives you allow and block only. Use at least three zones: a low-risk band that is allowed, a middle band that triggers step up or review, and a high-risk band that is blocked.
3. Size the middle band to your capacity. The review band should not exceed what your team can clear in the time you promise customers. If it does, tighten step up so more cases resolve automatically, or add capacity.
4. Test on real outcomes. Run proposed thresholds against historical applications where you know what happened, or run new rules in a monitoring mode first, recording what they would have done without enforcing it. Compare the results with your confirmed fraud, chargebacks and genuine customers who were wrongly stopped.
5. Set different thresholds for different journeys. A low-value sign-up and a high-limit account do not need the same cut-offs.
6. Write the rationale down. Record who set each threshold, when, and why. This becomes part of your audit trail.

This page does not give numeric thresholds because the right values depend on your customers, products and fraud exposure. Treat any figure quoted without that context with caution.

Step-up options

Step up works best when the request matches the doubt. Asking for everything every time recreates the friction you were trying to avoid.

• Document step up. Ask for a fresh capture, a second document, or a better-quality image when the issue is document quality, a data mismatch, or a doubt about authenticity. See document authentication.
• Selfie and liveness step up. Ask for a live selfie compared with the document photo when the concern is whether the person present is the person on the document, or when device and IP signals suggest someone other than the genuine owner. See biometric verification.
• Enhanced due diligence (EDD). For customers whose risk profile calls for it, such as a politically exposed person match or a higher-risk relationship under your policy, ask for further information, such as source of funds or wealth, and have it assessed by a person. EDD is a compliance-led step, not an automated one, and usually ends in review. See AML screening.
• Contact-point confirmation. Confirm control of an email address or phone number where those signals are the weak point.

After a step up, the new evidence goes back through the decision layer and the customer is re-decided: allow, review or block. A step up with no defined next outcome simply parks the customer. Where to place step-up triggers in the customer journey, and how to design the screens, belongs to the Designing a Risk-Based Onboarding Flow article.

Running a review queue

Review is where automation hands over to people, and a poorly run queue causes most of the delay and inconsistency customers experience.

What a reviewer needs

A reviewer should see the whole case on one screen: the applicant's data, each check result, which rules fired and why, any screening matches, and prior history for the same device, email or phone. If they have to open five tools to build the picture, decisions slow down and quality varies. The case review page describes how ScreenlyyID presents this.

Who reviews

That depends on the case type. Fraud and identity questions usually go to fraud or onboarding operations. Sanctions and PEP matches usually go to compliance or the money laundering reporting function, since these carry regulatory consequences. Smaller firms may have one person doing both; in that case, record which hat they are wearing for each decision. Escalation paths for complex cases should be defined in advance.

Making the queue work

• Prioritise. Order by risk and age so urgent cases and customers who have waited longest do not sit at the bottom.
• Standardise outcomes. Give reviewers a short, fixed set of decisions and reason codes rather than free text only, so outcomes can be analysed later.
• Use written guidance. Document what evidence clears a case, what leads to a decline, and when to escalate. Reviewers following the same guidance produce consistent decisions.
• Apply a second pair of eyes to blocks and high-risk approvals where your policy requires it.
• Feed results back. Every reviewer decision is labelled data. Cases the queue clears as genuine show where rules are too tight; confirmed fraud shows where signals were under-weighted.

Tuning: false positives against fraud loss

Every threshold trades two errors. A false positive is a genuine customer stopped, stepped up or sent to review unnecessarily. A false negative is a bad actor allowed through. Tightening reduces one and increases the other. You cannot eliminate both, so the job is to find the balance that fits your appetite, and to improve the signals so the whole trade-off curve improves.

Practical ways to reduce false positives without opening the door to fraud:

• Replace blunt rejects with step up. Many "decline" rules exist because there was no better option. Offering a selfie or document re-capture lets genuine customers prove themselves while fraudsters often drop out.
• Look at which rules generate the most reviewed-and-cleared cases. A rule that fires often and almost always clears in review is costing you time. Narrow it, lower its weight, or require another signal alongside it.
• Look at which rules generate the most confirmed fraud. Those earn their place and may deserve more weight.
• Segment. A rule that works for one country, channel or product may misfire for another. Adjust by segment rather than loosening everywhere.
• Change one thing at a time and measure. Alter a single rule or threshold, compare outcomes over a fixed period, and keep a record. Several simultaneous changes make results impossible to attribute.
• Allow for lagging outcomes. Fraud often shows up weeks later through chargebacks or account behaviour. Judge changes against delayed outcomes, not only the first-day approval rate.
• Watch for drift. Fraud patterns and customer behaviour change. A threshold that worked a year ago needs periodic review.

Track a small set of measures together rather than any single one: approval rate, step-up rate and completion, review volume and time to clear, confirmed fraud, and customer complaints about declines. An approval rate on its own can improve while fraud quietly rises.

Audit trail for regulators and internal control

Regulated businesses are expected to be able to show how they reached customer decisions and that their controls follow their own policies. Requirements differ by country and sector and change over time, so check the current rules with your regulator or legal counsel. The FATF publishes the international standards that many national regimes draw on.

Whatever the jurisdiction, a decision record is far more useful when it contains:

• the time of the decision and a customer or application reference;
• every input result used, including checks that returned no data;
• which rules fired and which thresholds applied, with the version of the logic in force at the time;
• the outcome and reason codes;
• for step up, what was requested and what was received;
• for review, who reviewed, when, what they decided and their notes;
• any manual override and who approved it;
• a change log for rules and thresholds showing who changed what and why.

Versioning matters more than people expect. Six months later, you may need to explain why a customer approved in March would be treated differently in September. Without a record of the rules as they stood in March, you cannot. Retention periods and data protection obligations also apply to this data; confirm them with counsel.

What a decision view should show

Whether you use ScreenlyyID or build your own, the screen where a decision is displayed should answer five questions at a glance: what was decided, which signals drove it, which rule or threshold triggered, what the next action is, and what a reviewer can do about it. A bare score fails this test, because nobody can act on a number they cannot explain. ScreenlyyID's decisioning and case review pages show the product's view, and you can see pricing or sign up to try the API.

Where this fits with the rest of your stack

Risk decisioning is the logic layer on top of verification, screening and fraud signals. If you are weighing one decision layer against several separate vendors, that is a strategy question covered in the KYC Orchestration article. For the wider set of fraud controls, start at the fraud detection hub, and for signal sources see IP and device intelligence, email validation and phone validation.

This article is general information, not legal advice. Check the current requirements with your regulator or legal counsel.