A customer paid three invoices from the same wallet without a problem. The fourth invoice arrives months later, and someone attaches the old screening result because the relationship is familiar. That record tells you what was checked earlier. It does not tell you what evidence is available now. Build a repeatable re-check policy around the payment workflow rather than treating the first result as permanent approval.
Decide what makes a new review necessary
Choose review points your team can actually follow: a new payment cycle, a changed sending wallet or network, an unexpected intermediary, or a discrepancy in the commercial record. These are suggested internal triggers, not A2 Route requirements or legally prescribed intervals. Assign an owner who can decide when a change needs a new check before staff release an order.
Keep the policy tied to the subject. If the customer changes the wallet, a result for the old address is not a result for the new one. If you are assessing an actual received transaction, do not describe the earlier address check as a check of that transfer. The incoming USDT guide covers matching the payment to the agreed instructions.
For training records, use FAKE_RECURRING_WALLET_NOT_AN_ADDRESS and FAKE_NEXT_PAYMENT_NOT_A_HASH. These deliberately invalid synthetic labels can show how a case file connects reviews without publishing real customer payment details. They are not live screening inputs.
Set an interval, but keep exceptions visible
There is no universal interval in this guide. A desk handling frequent settlements and a business receiving occasional invoices have different review workloads. Decide how often to revisit unchanged counterparties under your own policy, and write down why that interval fits the activity you actually handle. Do not present a suggested schedule as a guarantee of regulatory compliance.
Event-driven reviews can sit beside that schedule. An unexpected sender or new risk finding may need attention before the next routine review date. Conversely, avoid requesting repeated identical checks merely because several colleagues cannot find the most recent record. Give the team a clear location for the latest reviewed result and its timestamp.
This is a manual review workflow, not a description of a batch-upload function or a promise of automatic reminders. Use the current API documentation when selecting product features. Do not infer that several individual results form a product-generated portfolio summary with shared coverage or a common decision.
Re-check the same subject when comparing results
A2 Route's public scope covers addresses and USDT/USDC transactions on TRON and Ethereum. Record the network, address or transaction reference, check kind and time for each review. Comparing a wallet result with a different transfer result can be useful, but it is not a like-for-like comparison and should be described accordingly.
The public report description includes verdict, score, source shares, top exposure, sanctions lists and a risk-categories appendix. Compare the explanations and coverage, not only the score. The risk-score guide helps explain why a changed number alone does not establish a changed commercial risk or a finding of wrongdoing.
If a later result differs, first rule out a different subject, network or mode. Then write what changed in the recorded evidence. The sample limitations note that provider labels can change. Do not assume that a difference proves the customer took a particular action between checks; the evidence may not establish that explanation.
Treat reduced coverage as an unresolved issue
A2 Route's public FAQ describes partial results as reduced coverage and recommends a re-check. Keep that warning visible in your routine process. A recurring customer should not receive a less careful reading merely because earlier checks were reassuring. State who will obtain the later result and what happens to the payment while the evidence remains incomplete.
Retain earlier reports and review notes when a new result arrives. Overwriting the file removes the evidence available to the previous reviewer and makes later questions harder to answer. The report walkthrough explains the sample's timing, scope and limitations before you organise a recurring-customer archive.
Close each review with a short decision note
Record the trigger, checked subject, relevant finding, unanswered questions and decision owner. If the result is flagged, ask focused questions rather than treating the established relationship as an explanation. Use the counterparty review checklist to keep escalation and exceptions accountable.
For frequent desk activity, the OTC workflow guide shows how to attach review evidence to a trade ticket. A repeat customer can still send a different payment, and an incoming review does not approve the outgoing destination used later in the same deal.
For that separate supplier-payment leg, consult the A2vanta business payment blog. Start a supported A2 Route check and retain the result with your own records. Screening is an informational tool, not legal advice, a permanent wallet approval, a guarantee of clean funds or a promise that another institution will accept the payment.