Skip to main content

Goldsky

Crypto source of funds and wealth checks

Talk to our team

What it is

A crypto source of funds check traces where a client’s onchain money came from, and a source of wealth check uses the same history to show how the client built up what they hold; both belong to enhanced due diligence.

Banks and wealth platforms run them when a client arrives with crypto, because the onboarding file has to show that the funds have a legitimate origin before the client can move them in.

Goldsky gathers the full transfer history of the wallets the client declares and records your risk provider’s rating with its inputs; checking the client’s identity, and judging whether their explanation holds up, stay with your providers and your compliance team.

You can gather the wallet history two ways: load it into your own database with a one-time Turbo Pipelines job, or pull each wallet’s transfers from the Feeds transfers API when the case needs them.

Who it’s for

Global banks, private banks and wealth platforms, crypto-native banks and the transaction monitoring vendors they work with.

How a crypto source of funds check works

The diagram follows one client from declaring their wallets at onboarding to your team’s judgment on whether the history explains their funds. Your setup may differ.

Your business, step 1: Client onboardsThey declare the wallets holding their funds
Your business, step 2: KYC/KYB providerVerify identityThe client’s identity is checked first
Your business, step 4: Screening providerScore the sourcesRisk ratings for where funds came from
Goldsky, step 3: TurboLoad wallet historyEvery past transfer in and out, decoded
Your business, step 6: Judge the explanationYour team accepts it or asks for more
Goldsky, step 5: ComposeRecord the verdictA task fetches the rating and keeps it
  • Goldsky
  • Your provider

Ways to gather wallet history for a source of funds check

A one-time pipeline job writes decoded history into tables you query, including events from any contract the client used; the transfers API returns one wallet’s native and token transfers each time your code calls it.

Usual setupOption 1: Load history into your database
Best for
Long histories queried in your own database
Products
TurboCompose
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 client at a time, pulled when a case opens
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: Run a crypto source of funds check by loading history into your database

A one-time pipeline loads and decodes every past transfer of the client’s declared wallets into your database, and a task Goldsky hosts keeps your risk provider’s rating with the call that produced it.

When to load wallet history into your database

Clients arrive with long or busy wallet histories, or with funds that passed through contracts beyond plain token transfers, and your team wants to query the whole record next to its other case data.

What you’ll need

  • Goldsky Turbo
  • Goldsky Compose
  • An identity verification provider
  • A blockchain risk provider that rates wallets
  • A database for the decoded history and the ratings
  • A case management system where your team records its judgment

  1. Collect the wallets the client says hold their funds

    The check can only trace money in wallets you know about, so it starts with the client’s own list.

    The client declares each wallet and the chain it’s on, and proves they control it, for example by signing a message. A wallet they leave off the list is history you never see, so ask where the funds sit today and where they sat before.

  2. Verify the client’s identity

    A source of funds check explains one person’s or company’s money, so you need to know who they are first.

    Your identity verification provider checks the client against your onboarding policy. Tracing funds for someone whose identity hasn’t been confirmed produces a file that can’t be tied to anyone.

  3. Load and decode the wallets’ full history

    Handled by Goldsky Turbo

    The origin of the funds is in the transfers that brought them into the declared wallets, often years back.

    Every transfer in and out of each wallet has to be loaded from the first block, with token amounts and the contracts involved turned into readable fields (decoded). Raw records your team can’t read are evidence nobody can review.

    Turbo Pipelines can run a one-time job over a decoded dataset such as erc20_transfers, filtered to the client’s addresses, and decode other contracts’ events from raw_logs with _gs_log_decode(). The job writes to your database and exits once it reaches the block you set.

    Decode contract events (opens in a new tab)

  4. Rate the risk of where the funds came from

    A transfer history shows which wallets paid the client, but not whether those wallets belong to an exchange, a mixer or a sanctioned party.

    Your risk provider rates the wallets that sent funds in, using its own attribution of who controls them. Send it the counterparties from the history you gathered, so the rating and the history describe the same transfers.

  5. Keep the rating with the history it describes

    Handled by Goldsky Compose

    The file has to show which answer the provider gave about which transfers, on which day.

    Each request and response is stored with the case, and a failed call is retried without paying for an answer you already have. A rating pasted into a note can’t be traced back to the question that produced it.

    With Goldsky, a Compose task sends the counterparties to your risk provider through ctx.fetch, and the run log keeps the URL and response of each call. The task can save the rating to a collection keyed on the case.

    Make auditable calls with fetch (opens in a new tab)

  6. Judge whether the history explains the funds

    The check ends with a person deciding whether the client’s story and the chain agree.

    Your compliance team compares the history and the rating with what the client says, such as early purchases on an exchange or the sale of a business. Where they don’t line up, the team asks the client for more before onboarding goes ahead, and records why it accepted or declined.

What to know about loading wallet history into your database

  • Goldsky runs the job; you own the database it writes to and every query your team runs on it.
  • The job stops at the block you set, so a later deposit needs a new run or a live pipeline.
  • You choose the columns, so decoded events from other contracts can sit beside plain transfers.
  • Totals over the counterparties and periods in the client’s story, and matching transfers to that story, are queries you write in your database.

Option 2: Run a crypto source of funds check with a wallet transfers API

Your onboarding or case tool calls the Feeds transfers endpoint for each declared wallet and gets back its transfers in and out, with token details and the USD value at the time. Your code sends the counterparties to your risk provider and keeps the answers.

When to use a wallet transfers API

Checks happen one client at a time, at onboarding or when a case reopens, and native and token transfers are enough evidence for your team.

What you’ll need

  • Goldsky Feeds
  • An identity verification provider
  • A blockchain risk provider that rates wallets
  • Somewhere to store the responses with the case
  • A case management system where your team records its judgment

  1. Collect the wallets the client says hold their funds

    The check can only trace money in wallets you know about, so it starts with the client’s own list.

    The client declares each wallet and the chain it’s on, and proves they control it, for example by signing a message. A wallet they leave off the list is history you never see, so ask where the funds sit today and where they sat before.

  2. Verify the client’s identity

    A source of funds check explains one person’s or company’s money, so you need to know who they are first.

    Your identity verification provider checks the client against your onboarding policy. Tracing funds for someone whose identity hasn’t been confirmed produces a file that can’t be tied to anyone.

  3. Pull each wallet’s transfer history

    Handled by Goldsky Feeds

    The origin of the funds is in the transfers that brought them into the declared wallets.

    The request has to cover every wallet, every chain it’s on and the whole period the client describes, including tokens with no market price. A window that starts too late or leaves tokens out hides the transfers the check is meant to find.

    Feeds returns one wallet’s native and ERC-20 transfers across chains from its transfers endpoint, each with its counterparty and USD value at transfer time. Set include_unknown_price=true so transfers of tokens with no price source aren’t left out.

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

  4. Rate the risk of where the funds came from

    A transfer history shows which wallets paid the client, but not whether those wallets belong to an exchange, a mixer or a sanctioned party.

    Your risk provider rates the wallets that sent funds in, using its own attribution of who controls them. Send it the counterparties from the history you gathered, so the rating and the history describe the same transfers.

  5. Keep the rating with the history it describes

    The file has to show which answer the provider gave about which transfers, on which day.

    Store the transfer response, the provider’s request and its answer together with the case. If the history is pulled again later, values and rows can differ, so the copy your team judged is the one to keep.

  6. Judge whether the history explains the funds

    The check ends with a person deciding whether the client’s story and the chain agree.

    Your compliance team compares the history and the rating with what the client says, such as early purchases on an exchange or the sale of a business. Where they don’t line up, the team asks the client for more before onboarding goes ahead, and records why it accepted or declined.

What to know about using a wallet transfers API

  • Your code pulls each wallet when a case needs it, and nothing is kept unless you store it.
  • The response covers native and token transfers in a fixed shape, without other contract events.
  • USD values are worked out at request time and can change later, so save what your team relied on.
  • A transfer undone by a reorg stops appearing in responses with no flag, so record the block of each one you use.

What you control

Your team
  • Collect the wallets the client says hold their funds
  • Judge whether the history explains the funds
Your providers
  • KYC/KYB provider
  • 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

Run a crypto source of funds check 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