Transaction screening workflow (concepts)

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:

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

1. 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.
2. 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):

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.