Learn-skills.dev transaction-screening-workflow-concepts

Educational map of transaction-centric compliance screening—transfer as the atomic unit, deposit vs withdrawal direction, single and CSV import, transaction list and detail views, per-transfer screening, rescreen, and STR-style exports. Use when the user asks how monitoring UIs treat tx hashes, directions, or regulatory reporting hooks—not for legal filing advice or evading reporting.

install
source · Clone the upstream repo
git clone https://github.com/NeverSight/learn-skills.dev
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/NeverSight/learn-skills.dev "$T" && mkdir -p ~/.claude/skills && cp -r "$T/data/skills-md/agentic-reserve/blockint-skills/transaction-screening-workflow-concepts" ~/.claude/skills/neversight-learn-skills-dev-transaction-screening-workflow-concepts && rm -rf "$T"
manifest: data/skills-md/agentic-reserve/blockint-skills/transaction-screening-workflow-concepts/SKILL.md
source content

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 fromto 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:

DirectionTypical screening focus
DepositInflow to the platform/customer relationship—provenance of funds arriving.
WithdrawalOutflow 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

  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):

FieldPurpose
ChainNetwork identifier per template
Transaction hashOn-chain tx id
LabelOptional private label
DirectionOptional
Deposit
/
Withdrawal
Customer IDOptional internal customer key
Transfer From / Transfer ToOptional 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 transfersGraph 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 logComments 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.