Skip to main content

Goldsky

Crypto wallet screening and sanctions data

Talk to our team

What is crypto wallet screening?

Crypto wallet screening, also called address screening or sanctions screening, is checking the sender and the recipient of each onchain transfer against a list of sanctioned or high-risk wallet addresses.

Exchanges, sponsor banks and stablecoin issuers run it so that every transfer touching a listed address reaches their compliance team, which decides whether to clear it, escalate it or report it.

Goldsky streams the transfers, checks both sides against the list you load from your sanctions data provider and hands each hit to your queue or case tool; the list, the review and every decision stay with you.

You can screen wallets two ways: stream every transfer through a screening pipeline with Turbo Pipelines, or pull one wallet’s transfers from the Feeds transfers API when your team reviews it.

Who uses crypto wallet screening?

Crypto exchanges, sponsor banks, stablecoin issuers and KYT vendors that screen customer transfers against sanctions lists.

How crypto wallet screening works

Two inputs meet in this chart, a transfer on the chain and the list from your sanctions provider, and it follows them to the case your team reviews. Your setup may differ.

Your business, step 1: Screening providerSupply the listListed addresses loaded into your watch list
Goldsky, step 2: TurboKeep the list currentNew listings reach screening without downtime
Blockchains, step 3: Transfer madeTokens move between two wallets
Goldsky, step 4: TurboScreen both sidesSender and recipient checked against the list
Your business, step 7: Review the caseYour team clears, escalates or reports it
Goldsky, steps 5–6: TurboQueue the hitEach hit lands on your message queue
or
Goldsky, step 5: TurboSend an alertEach hit posts to your case tool
  • Goldsky
  • Your provider

Ways to screen crypto wallets against sanctions lists

The pipeline screens every transfer as it arrives and pushes each hit to you; the transfers API returns one wallet’s transfers when your code calls it, and your code checks them against the list.

Usual setupOption 1: Stream and screen
Best for
Every transfer screened on arrival, hits pushed to you
Products
Turbo
What you run
The destination: your database, queue or bucket, or a Postgres database Goldsky hosts
What you write
Pipeline YAML and SQL; TypeScript transforms when needed
Where your data lives
In your own database or systems
How results reach you
Pushed to you
Option 2: Wallet transfers API
Best for
One wallet at a time, at onboarding or review
Products
Feeds
What you run
Nothing; you call an endpoint and keep what you need
What you write
REST requests
Where your data lives
Hosted by Goldsky
How results reach you
Returned when you call

Option 1: Screen crypto wallets against sanctions lists by streaming every transfer

A pipeline Goldsky runs reads every transfer of the tokens you watch, checks the sender and the recipient against your list, and sends each hit to your message queue or case tool. The list sits in a database table you update, and the running pipeline applies each change without a redeploy.

When to screen every transfer with a pipeline

You need every transfer of your asset, or of your customers’ wallets, screened as it happens, and a list update to apply from the next transfer without a release.

What you’ll need

  • Goldsky Turbo
  • A sanctions list or risk data provider
  • A database for the watch list
  • A message queue, or a case tool with a webhook endpoint
  • A compliance team that reviews each hit

  1. Load the sanctions list

    Screening only catches addresses that are on your list, so the list comes first.

    Your sanctions data provider supplies the listed wallet addresses, and your team adds its own blocklist. Store every address in one format, such as lowercase, because an address written another way won’t match.

  2. Keep the list current while screening runs

    Handled by Goldsky Turbo

    Lists change without warning, and a newly listed address has to be checked from the next transfer on.

    Updates have to reach the running screen without a release or a restart. If an update waits for the next deploy, transfers to that address pass unflagged in the meantime.

    With Goldsky, the watch list is a Turbo Pipelines dynamic table, which lives in a Postgres database you can keep inside your own compliance boundary. Your list-loading job inserts a row and the running pipeline starts flagging that address, with no redeploy.

    Learn about dynamic tables (opens in a new tab)

  3. A transfer is made onchain

    Tokens move between two wallets, and either of them could be on the list.

    The transfer is recorded in a block anyone can read. For a short time the newest blocks can still be replaced (a reorg), so a transfer seen once can still move or disappear.

  4. Check both sides of every transfer

    Handled by Goldsky Turbo

    Either the sender or the recipient can be the listed party, so both have to be checked.

    Every transfer of the tokens you watch has to be read, both addresses compared with the list, and each hit recorded with the token, the amount, the transaction and which side matched. Checking only incoming transfers misses funds your customers send to a listed wallet.

    A Turbo Pipelines SQL transform checks the sender and the recipient with dynamic_table_check(), keeps only transfers where one of them matches, and labels which side hit.

    Match addresses with dynamic tables (opens in a new tab)

  5. Send each hit to your queue or case tool

    Handled by Goldsky Turbo

    A hit only helps once it reaches the people who review it.

    Each hit goes to one place your team works from: a message queue your systems read, or the alert endpoint of your case tool. Delivery can repeat after a network error or a restart, so the receiver checks each hit’s ID and skips one it has already opened a case for.

    Goldsky can publish each hit to a Kafka topic keyed on the transfer id, or post it to your case tool through a webhook sink with one_row_per_request: true, so every hit arrives as its own request.

    Set up the webhook sink (opens in a new tab)

  6. Correct hits undone by a reorg

    Handled by Goldsky Turbo

    Now and then the chain replaces its newest blocks (a reorg), and a transfer you flagged can disappear or move.

    Your queue consumer or case tool has to act on the correction: close the case if the transfer is gone, or update it if the transfer landed in another block. Left alone, the case points at a transaction that no longer exists.

    Turbo Pipelines passes reorg corrections through as records of their own. A queue or webhook consumer receives them and applies them, and a database table with a primary_key, if you keep one as well, is corrected in place.

    How reorgs reach your sinks (opens in a new tab)

  7. Review the case

    A list match is a lead, and a person decides what it means.

    Your compliance team checks the match, looks at the customer and the funds, and clears, escalates or reports the case under your policy. Keep the transfer, the list entry that matched and who decided what in the case record, because an examiner may ask for all three.

What to know about screening every transfer with a pipeline

  • Goldsky runs the pipeline; the list, the queue or case tool it delivers to, and every decision on a hit are yours.
  • The pipeline flags transfers whose addresses are on the list. It doesn’t score risk or decide what a hit means.
  • Hits are sent when a transfer is seen, before it’s final, so a queue or webhook consumer receives correction records after a reorg and applies them.
  • A list change applies to transfers the pipeline reads after it, so past transfers to a newly listed address need a separate look back.

Option 2: Screen crypto wallets against sanctions lists with a transfers API

Your team or your app calls the Feeds transfers endpoint for one wallet’s transfers when it needs them, at onboarding or when a case is reviewed, and your own code compares every counterparty with the list. There’s no pipeline or watch-list table to run.

When to screen with a wallet transfers API

You review wallets one at a time, at onboarding or when a case opens, and don’t need every transfer screened the moment it lands.

What you’ll need

  • Goldsky Feeds
  • A sanctions list or risk data provider
  • Code that compares counterparties with the list
  • A case management tool
  • A compliance team that reviews each hit

  1. Load the sanctions list

    Screening only catches addresses that are on your list, so the list comes first.

    Your sanctions data provider supplies the listed wallet addresses, and your team adds its own blocklist. Store every address in one format, such as lowercase, because an address written another way won’t match.

  2. Choose the wallet to review

    This way checks one wallet at a time, so something has to start each check.

    A new customer’s onboarding, a withdrawal request or an analyst opening a case decides which wallet is checked, and on which chains. A wallet nobody looks up is never screened, so write the events that trigger a check into your policy.

  3. Pull the wallet’s transfers

    Handled by Goldsky Feeds

    To screen a wallet’s past, you need every wallet it has sent funds to or received them from.

    The lookup has to cover every chain and token the wallet uses, and page until the results run out. How far back the history goes can differ by chain, so note the earliest date each check covered.

    Feeds returns a wallet’s native and ERC-20 transfers across the chains you name, newest first, with the counterparty on every row. Set include_unknown_price=true so transfers in tokens without a price aren’t left out, and follow page_token to the last page.

    Read the transfers endpoint reference (opens in a new tab)

  4. Check each counterparty against the list

    The screen itself is a comparison between the wallets this one dealt with and the list.

    Your code compares the counterparty on every transfer with the list, in the same address format, and records each match with its transaction and date. A match on an old transfer can still matter, and your policy decides how far back counts.

  5. Review the case

    A list match is a lead, and a person decides what it means.

    Your compliance team checks the match, looks at the customer and the funds, and clears, escalates or reports the case under your policy. Keep the transfer, the list entry that matched and who decided what in the case record, because an examiner may ask for all three.

What to know about screening with a wallet transfers API

  • Your code pulls, so a listed counterparty shows up only when someone calls the API for that wallet.
  • The list and the comparison live in your code; the endpoint returns transfers, not risk scores.
  • A transfer undone by a reorg stops appearing in responses with no flag, so a hit you saved can point at a transfer that’s gone.
  • Transfers come back without their own ID, so your code decides how to tell a repeat from a second, identical transfer.

What you control

Your team
  • Review the case
Your providers
  • Screening provider

Security and deployment

  • SOC 2 Type IIIndependently audited security controls.
  • Dedicated infrastructureSingle-tenant options for production workloads.
  • Data residencyCloud, on-premises or co-located.

More use cases that monitor transactions

Screen crypto wallets against sanctions lists with Goldsky

We’ll map it to your systems and show you what Goldsky runs, so your team builds the product, not the pipelines underneath it.

Talk to our team

© Endless Sky Inc. All rights reserved.

PrivacyTermsSecurity

System status