How payment screening results work

Every payment you send to an external recipient is screened before it can be signed. The result appears on the payment as a risk dossier, and it carries one overall verdict.

That verdict is not a single risk number. It is a summary of around fifteen separate checks that run against the destination address, your own policy rules, and how the payment compares with your organisation's normal activity. This page explains what the verdicts mean, what the checks look for, and what you can do about each result.

The four results

PASS is not an instruction to sign. It means nothing automated objected. Your own judgement still applies, and you remain responsible for the payment.

FLAG locks the payment. It cannot be signed until every flag is resolved with a written comment. Some flags need more than a comment, see "Resolving a flag" below.

BLOCK locks the payment with no path to signing it in the app. Reject and archive it. If you believe the payment is legitimate, raise it with your account manager rather than trying to route around the result.

CHECKING usually lasts moments. You can close the page, screening continues in the background and the payment updates itself when the result arrives. If a payment sits on Checking far longer than usual, contact support.

How the separate checks combine

Two rules govern the overall verdict, and they are the part people most often misread.

The overall result is the most serious single check. Fourteen checks passing and one blocking gives you a blocked payment. The verdict summarises the worst thing found, not the average. This is why a payment can be blocked while most of the dossier looks green: open the dossier and read the one check that objected.

Smaller signals add up. Several checks raise a mild concern rather than a decisive one. Individually none of them holds a payment. Together they can raise the overall result, because a payment that is unusual in four different ways at once is a different proposition from one that is unusual in a single way. So you may see a flag where no single check looks alarming on its own.

Both rules apply to the whole dossier. There is no one check that overrides the rest.

The risk score

Alongside the verdict, a payment carries a risk score, shown in the Risk column of the signing queue and as a gauge on the payment itself, labelled low, medium, or high.

The score is the single most misread thing on the screen, so it is worth being precise about what it is.

The score describes the destination address, not the payment. It summarises what is known about the address you are about to pay: how directly and how heavily its funds trace to sanctions exposure, stolen coins, scams, darknet services, mixers, and similar categories. A recipient with a long clean history scores low. A recipient whose funds have recently come through a mixer scores high.

A low score is not a PASS. This is the mistake to guard against. The address checks are one of four groups in the dossier. A payment to a spotlessly clean address is still flagged if it is your first payment to it, if it is far larger than you normally send, if the required invoice is missing, or if it is one of a run of payments sized just under your approval limit. A low score narrows the question to "is this address dangerous", and the answer being no does not make the payment right.

*Example: you pay a long-standing supplier's address, which scores low, but the amount is ten times your usual. The payment is flagged. Nothing is wrong with the address, and that is not what was flagged.*

What the score does to the result. The address check turns the score into one of the three results, on a scale of zero to one hundred:

These bands apply to the address check only. They decide what that one check says, not what the payment's overall verdict is. A payment whose address scores in the passing band is still flagged or blocked if any other check objects, and that is the normal case rather than the exception.

The number shown is rounded, so a score sitting exactly on a boundary can behave as the band below it.

The gauge is shaded on these same bands: green for a passing score, amber for a flagging one, red for a blocking one. The colour tells you about the address. It does not tell you the payment's verdict, which depends on every other check as well.

A score is not a probability and does not add up across payments. It is a summary of exposure, not a percentage chance that the payment is fraudulent. Two payments scoring the same do not carry the same risk if one is for a small routine amount and the other is your quarter's revenue.

A dash means there is no score yet, not a score of zero. You will see a dash while screening is still running, and on rows that are not payments at all, such as governance approvals. Do not read a blank as clean.

A batch shows its worst recipient's score. A batch is only as safe as its riskiest destination, so one bad address in a list of fifty sets the number you see on the batch row. Open the batch to find which recipient it came from.

The same address can score differently over time. Scores reflect what is currently known about an address and its funding history. An address that scored low six months ago can score high today without you having done anything, because of who has paid it since.

Read the score as the opening question, then read the checks for the answer. The verdict, not the number, is what governs whether the payment can be signed.

What we check

The dossier groups its checks into four kinds.

The destination address

Sanctions and watchlists. We check the recipient's address against international sanctions lists and watchlists. A confirmed match stops the payment. A weaker sanctions-related signal, short of a listing, raises it for review instead.

*Example: you are paying a new trading partner, and the address they gave you is itself on a sanctions list. The payment is blocked and cannot be sent.*

On-chain associations. We check whether the address has been linked to scams, theft, or other on-chain risk, based on where its funds have come from and gone to. This check is what produces the risk score described above. A strong link stops the payment. A weaker or more distant one raises it for review, because plenty of legitimate addresses have some indirect exposure.

*Example: the address you are paying previously received funds that came out of a known exchange hack. Depending on how direct and how substantial that link is, you will see either a flag asking you to confirm you know who you are paying, or a block.*

When screening cannot complete. If the address checks cannot return a result, the payment is raised for review rather than allowed through quietly. An unscreenable payment is treated as an open question, not as a pass.

Your own policy rules

These checks measure the payment against the thresholds your organisation configured. They are yours, and an Admin can change them in your policy settings.

Approval requirements. Explains how many people need to approve this payment before it can be sent, and whether one person can approve it alone. This check is informational. It tells you what will be required, it does not object.

*Example: the dossier tells you the payment is within your self-approval limit, so you can sign it by yourself, or that it needs your full signing quorum.*

Supporting document. Shows whether a supporting document, such as an invoice, is needed for a payment of this size, and whether one is attached. If you attached a document when you created the payment, this resolves itself.

*Example: you raise a large supplier payment without attaching the invoice. You get a flag, and the only way to clear it is to upload the invoice.*

New recipient. Highlights the first payment you make to a brand-new address, one that is not yet in your saved counterparties and that you have never paid.

*Example: a supplier emails you new bank details and a new wallet address. This check makes sure that fact is put in front of a human rather than passing silently, which is the single most common way invoice fraud succeeds.*

How the payment compares with your normal activity

These checks learn what normal looks like for your organisation, then notice when a payment does not fit. They need history before they can say anything useful, so on a new account they stay quiet and report that they are still building a picture.

None of these checks is an accusation. Each one is a question: is this you?

Time of day. Notices when a payment is made at an unusual time of day compared with your normal activity, measured in your organisation's timezone.

*Example: your team pays suppliers during European business hours. A payment goes out at four in the morning. That is worth a second look, whether or not it turns out to be a deadline you were chasing.*

Payment frequency. Notices when you are making many more payments than usual in a short time.

*Example: you normally raise a handful of payments a day, and suddenly there are dozens within an hour. Payroll day explains it. A compromised account also explains it.*

Payment size. Notices when a payment is much larger than you normally send for this token and network.

*Example: your usual payment on a given network is a few thousand. This one is ten times that. It will raise this check even if the recipient is one you have paid many times before.*

Recipient history. Tells you whether you have paid this address before.

*Example: an address you have paid monthly for a year raises nothing. An address you have never paid is called out, so a wrong or substituted address does not slip through on autopilot.*

Token and network familiarity. Tells you whether you have used this token and network before.

*Example: you settle everything on one network, and a payment appears on a network your organisation has never used. Sometimes that is a customer's genuine preference. Sometimes it is someone moving funds where you are less likely to be watching.*

Many new recipients at once. Notices when you are suddenly paying many different new addresses at once.

*Example: a normal week has payments to a stable set of counterparties. A burst of payments to a dozen addresses you have never seen looks like a treasury being emptied, and is treated as such until someone confirms otherwise.*

Location and device. Confirms the request came from your usual location and device.

*Example: you always work from the same office and laptop, and a payment is raised from an unfamiliar network on an unfamiliar device. This is one of the earliest signals that an account has been taken over.*

Similar-amount sequences. Notices several near-identical payments that could be one larger payment split into smaller ones.

*Example: instead of a single large payment, a series of similar smaller ones appears over a short period, each one small enough not to attract attention on its own. Splitting a payment to stay under a control is a recognised pattern, and it is one your auditors will ask whether you monitor.*

Payments sized just under your approval limit. Notices payments deliberately sized to sit just below the point where a second approver would be required.

*Example: your self-approval limit is a round number, and a run of payments appears just underneath it. One such payment is coincidence. A pattern of them is not.*

Because these last two checks describe someone working around your own controls, they carry an extra rule, see "Resolving a flag".

Practical checks

Balance. Checks that the wallet holds enough of the token to make the payment. If it does not, the payment is blocked, because it would fail on the network anyway. Fund the wallet and the check clears on its own.

Resolving a flag

A flag is not a refusal. It is a request for a person to record why the payment is acceptable.

A written comment is required. It is stored permanently with the payment and appears in the evidence pack. Write for someone reading it in two years with no memory of the day. "Confirmed new bank details with the CFO by phone" is a resolution. "OK" is not.

Resolving does not erase the flag. The check stays in the dossier exactly as it was found. Your reasoning is added alongside it. The record shows what was flagged, who cleared it, when, and why.

Some flags need a document. Where the flag is that supporting evidence is missing, a comment alone will not clear it. You have to upload the document.

Some flags cannot be cleared by the person who raised the payment. The two checks about working around your own controls, similar-amount sequences and payments sized just under your approval limit, require a different approver to review them. This is deliberate: a control that the person being questioned can clear themselves is not a control. If you raised the payment and cannot resolve the flag, that is the rule working, not a fault.

A flagged payment may need more approvers than usual. Where either of those two checks has flagged, the option to approve the payment on your own is withdrawn and your full signing quorum applies, whatever the amount.

What is handled differently

Transfers between your own wallets. When the destination is a wallet your own organisation holds, the payment is recognised as internal and goes through a shortened set of checks. Screening a payment to yourself against a sanctions list tells you nothing.

Payments in a batch. Every recipient in a batch is checked individually. The batch takes the result of its riskiest recipient, so one blocked address in a list of fifty holds the batch. You resolve flags on the batch, and the dossier shows which recipients caused them.

What is recorded

The dossier is stored with the payment, not recalculated when you look at it later. It appears in the evidence pack and can be reconstructed exactly as it stood when the decision was made, together with who decided, what they wrote, and when.

A verdict applies to that payment at that moment. Raising the same payment tomorrow can produce a different result, because both the address and your own activity will have moved on.

Screening supports your compliance programme. It does not replace it, and it does not tell you what your obligations are. Those remain yours.

Common questions

The same address passed last week and is flagged now. Two things can cause this. Re-screening may have found something new about the address, since on-chain risk is not static. Or the address is fine and a behavioural check fired, because this particular payment does not fit your pattern. The dossier names which one.

Everything is flagged. Your policy thresholds are probably set low for the volume you actually run. Review them with an Admin. Thresholds that flag every payment train people to click through flags without reading them, which is worse than having no flags at all.

A blocked payment I believe is legitimate. It cannot be sent from the app. Contact your account manager. Do not try to send it another way, and do not split it into smaller payments, which will trip further checks and looks materially worse in the record.

A check shows no result. Screening could not complete that check. Do not read a blank as a pass. If it persists, contact support.

The risk score is low but the payment is still flagged. The score covers the destination address only. The flag will have come from your own policy rules or from how this payment compares with your normal activity. The dossier names which check objected.

I raised the payment and I am the only approver, and I cannot clear the flag. If the flag is one of the two about working around your own controls, there is no way for you to clear it yourself, by design. Contact your account manager. If your organisation routinely has only one approver available, that is worth revisiting separately, because several of these controls assume a second person exists.

Why does a check exist that never seems to object? Several checks are informational by design. They tell you how many approvers are needed or whether the payment is within your limits. They inform the decision rather than gate it.

Can I turn a check off? The thresholds you configured are yours to change in your policy settings. The address and sanctions checks are not optional.