Transaction screening workflow (concepts)
Educational reference only. Limits (batch sizes, engines, STR formats) change by product and jurisdiction—confirm in phalcon-compliance-documentation and your compliance program. Pair with address-screening-workflow-concepts (wallet inventory) and risk-exposure-screening-concepts (how direction affects participant and flow rules).
Unit of analysis
- The smallest screening unit is often a single transfer (asset movement from from → to within a tx).
- One transaction (one hash) may contain many transfers. Products may let you screen each transfer, subset, or roll up to transaction-level risk—behavior varies by vendor.
Direction (deposit vs withdrawal)
Setting Deposit vs Withdrawal steers which rules and which side of the flow the engines emphasize:
| Direction | Typical screening focus |
|---|---|
| Deposit | Inflow to the platform/customer relationship—provenance of funds arriving. |
| Withdrawal | Outflow and destination—where funds leave toward. |
Common product behavior (verify in docs):
- Rules can be scoped to one direction (for example deposit-only policies do not run on withdrawal-labeled items).
- If no direction is set, some products default to running both deposit- and withdrawal-oriented passes to reduce misconfiguration.
- Correct direction is used to tune rules and reduce false positives—it is an operational control, not a legal classification.
This aligns with participant/flow screening notes in risk-exposure-screening-concepts.
Labels
Labels are user-defined strings for organization and case context on a transaction or transfer (distinct from address tags/markers in address-screening-workflow-concepts).
Import methods
- Single transaction hash — Paste a hash; the product fetches parsed transfers; you select which transfer(s) to screen and attach direction, labels, and customer linkage.
- Bulk CSV — Template-driven import of many rows (batch size caps are product-specific—on the order of hundreds per file in some docs).
Typical CSV-style columns (names vary):
| Field | Purpose |
|---|---|
| Chain | Network identifier per template |
| Transaction hash | On-chain tx id |
| Label | Optional private label |
| Direction | Optional Deposit / Withdrawal |
| Customer ID | Optional internal customer key |
| Transfer From / Transfer To | Optional pair to disambiguate one transfer inside a multi-transfer tx |
Review per-row import outcomes in the UI.
Transaction list
Lists commonly show: hash, risk summary, screening direction, open alerts, last screened, notional (often USD), token amount, asset, from/to, timestamp, customer, labels, added time. Multi-transfer rows may collapse with expand to child transfers.
Transaction details page
Typical sections:
- Basic information — Asset, time, labels, customer, etc.
- Risk summary — Rolled-up alert view.
- Risk overview — Finer breakdown: risk categories, exposure-style charts, exposed address lists, fund-flow narrative; products may link to an external graph or trace tool where integrated.
- Token transfers — Graph plus tabular list of each transfer; per-transfer alerts; unscreened legs may be screenable on demand.
- Transfers overview — Compact index with shortcuts into each transfer.
- Alerts — Filterable list.
- Audit log — Comments and system events (same idea as address workflow).
Rescreen — Re-run screening for the whole transaction or a specific transfer; direction may be set per run.
STR-style and regulatory exports
Some products expose Suspicious Transaction Report (STR) or regional equivalents:
- Region selection matters—formats and fields differ by jurisdiction.
- Direction is often a prerequisite for valid STR generation in the product model.
- Reports may be generated per transfer when policy requires transfer-level suspicious activity narratives.
Not legal advice. STR obligations depend on local law and institutional policy; use qualified compliance and legal review for filings.
Deleting a transaction
Removing a transaction record typically deletes associated transfers and expires related alerts in the product. Public-chain data remain on explorers.
Guardrails
- Do not paste live production tx hashes tied to identifiable customers into public channels.
- Do not assist with structuring flows to evade monitoring or mis-labeling direction.
- STR and travel rule questions need program-specific guidance beyond generic skills.
See also
- address-screening-workflow-concepts — wallet inventory, tags/markers, blacklist/whitelist.
- behavioral-risk-screening-concepts — velocity and amount heuristics that may surface at transfer level.
Goal: a portable mental model of transaction screening UIs and direction semantics aligned with common compliance products, without binding a specific vendor implementation.