Skip to main content

Goldsky

Crypto trading data for bank and broker clients

Talk to our team

What is crypto trading data for bank and broker clients?

Crypto trading data for bank and broker clients is the position and profit-and-loss (PnL) record a bank or broker keeps for each client who buys and sells crypto through them.

The firms run the trading through a crypto provider, but the client expects their crypto on the same screen and statement as everything else, with what it cost and what it’s worth.

Goldsky supplies each client wallet’s transfers with their dollar value at the time, while the cost-basis method, the PnL figures and the client statement stay with you.

You can build it two ways: pull each client’s transfers with dollar values from the Feeds transfers API, or stream every client wallet’s transfers into your database with Turbo Pipelines.

Who uses crypto trading data for bank and broker clients?

Retail banks, brokerages, wealth platforms and neobanks that let clients buy and sell crypto through a crypto provider.

How crypto positions and PnL reach bank and broker clients

The diagram follows one trade from the client placing it to the position and PnL on their statement, and shows who does each step. Your setup may differ.

Your business, step 1: Client places a tradeA buy or sell in your banking app
Your business, step 2: CustodianSettle the tradeYour custodian moves the assets
Blockchains, step 3: Assets moveCoins land in the client’s wallet
Your business, step 5: Calculate positions and PnLYour system works out cost basis
Goldsky, step 4: FeedsPull priced transfersEach transfer with its USD value then
Your business, step 6: Show the clientPositions and PnL on their statement
  • Goldsky
  • Your provider

Ways to track crypto positions and PnL for clients

The transfers API returns one wallet’s transfers when you call it, while the pipeline keeps every client’s transfers in your database beside your books; either way, positions and PnL are yours to calculate.

Usual setupOption 1: Transfers API
Best for
An app team, positions built from API calls
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 2: Stream to your database
Best for
Every account, with position history in your database
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 1: Track client crypto positions and PnL with a transfers API

Your system calls the Feeds Transfers endpoint for each client wallet and gets back every transfer with its dollar value at the time. You turn those into positions and PnL with your own cost-basis rules.

When to use a transfers API for client positions

An app team without data engineers is adding crypto to a banking or brokerage app, and client wallets are on chains the API covers.

What you’ll need

  • Goldsky Feeds
  • A crypto provider that executes and holds client trades
  • A record of which wallet belongs to which client
  • Your own position and PnL logic
  • A current price source for open positions

  1. Take the client’s order

    Clients buy and sell crypto inside the banking or brokerage app they already use.

    Your app records the order against the client’s account, with the asset, the amount and the price agreed. That record is what the onchain movement is later checked against, so it needs your own order ID.

  2. Settle the trade with your crypto provider

    Most banks and brokers buy, sell and hold the coins through a crypto provider instead of running that themselves.

    The provider executes the order and moves the coins under its custody arrangement with you. Keep its trade confirmation with your order ID, because it’s the only record of trades that don’t move coins on the chain.

  3. Move the coins on the chain

    A settled trade shows up onchain as a transfer when it changes what an address holds.

    If your provider keeps a wallet for each client, the trade lands as a transfer into or out of that wallet. Providers that hold many clients in shared wallets record some trades only in their own books, so confirm with yours which setup you have before relying on the chain for positions.

  4. Pull each client’s transfers with their value

    Handled by Goldsky Feeds

    Positions and PnL are built from what moved into and out of each client wallet, and what it was worth then.

    The lookup covers every transfer since you last checked, in both directions, with the dollar value at the time of each. Without that value, cost basis has to be filled in from another source, and the two rarely line up.

    Goldsky’s Feeds Transfers endpoint returns a wallet’s native and ERC-20 transfers with price_usd and amount_usd at transfer time; pass from and to to fetch only the window since your last run.

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

  5. Calculate positions and PnL

    Clients want to see what they hold, what it cost them and how much they’ve made or lost.

    Your system adds up each client’s quantity per asset and applies your cost-basis method, such as first in, first out, to work out realized PnL (profit or loss on what was sold). Book the dollar value of each trade when you record it, so a later price correction doesn’t change last month’s statement.

  6. Show positions and PnL to the client

    Clients check their crypto next to their other accounts, on the screen and on their statement.

    Your app shows each position, its cost and its gain or loss, with current values from the price source you use elsewhere. Unrealized PnL (on what the client still holds) moves with the market, so the statement records the price and time it was taken at.

What to know about building positions from a transfers API

  • Your system pulls, so positions are as fresh as the last call.
  • Dollar values are worked out at request time, so book the value when you record each trade.
  • Transfers come back without their own ID, and a transfer undone by a reorg stops appearing in responses.
  • Position and PnL logic stay in your code.

Option 2: Track client crypto positions and PnL by streaming to your database

A pipeline loads each client wallet’s past transfers, then writes every new one to your database as it happens. Your position and PnL logic runs on those tables, beside your books.

When to stream client trades to your database

You need every client account covered, with unrealized PnL and position history, kept in your own database next to the rest of the client’s records.

What you’ll need

  • Goldsky Turbo
  • A crypto provider that executes and holds client trades
  • A database for the wallet list and transfers
  • Your own position and PnL logic
  • A current price source for open positions

  1. Take the client’s order

    Clients buy and sell crypto inside the banking or brokerage app they already use.

    Your app records the order against the client’s account, with the asset, the amount and the price agreed. That record is what the onchain movement is later checked against, so it needs your own order ID.

  2. Settle the trade with your crypto provider

    Most banks and brokers buy, sell and hold the coins through a crypto provider instead of running that themselves.

    The provider executes the order and moves the coins under its custody arrangement with you. Keep its trade confirmation with your order ID, because it’s the only record of trades that don’t move coins on the chain.

  3. Watch every client wallet

    Handled by Goldsky Turbo

    You only record trades for wallets you’re watching, so each new client wallet has to go on the list.

    The list changes as clients open and close crypto accounts, and it has to update without a restart. A wallet missing from the list shows a client a position of zero.

    With Goldsky, you can hold client addresses in a Turbo Pipelines dynamic table, which lives in a Postgres database, and add each new wallet as a row while the pipeline runs.

    Learn about dynamic tables (opens in a new tab)

  4. Load each wallet’s past transfers

    Handled by Goldsky Turbo

    Cost basis depends on every buy since the client started, so history has to be there before PnL is right.

    Past transfers are loaded once, from each wallet’s first activity. A load that starts too late puts the wrong cost on everything the client still holds.

    A Turbo Pipelines job (job: true) over a bounded block range writes the wallets’ past transfers to your database and exits when the range is done.

    Run a one-time backfill job (opens in a new tab)

  5. Move the coins on the chain

    A settled trade shows up onchain as a transfer when it changes what an address holds.

    If your provider keeps a wallet for each client, the trade lands as a transfer into or out of that wallet. Providers that hold many clients in shared wallets record some trades only in their own books, so confirm with yours which setup you have before relying on the chain for positions.

  6. Write every new transfer to your database

    Handled by Goldsky Turbo

    Positions update when a trade settles, so each transfer has to reach your tables as it happens.

    Each transfer needs a stable ID so a repeated delivery doesn’t count twice, and rows undone by a reorg have to come out again. Without both, positions drift from what the client holds.

    Turbo Pipelines writes each matching transfer to a database sink keyed on its id, and passes reorg corrections through as deletes and updates to the same rows.

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

  7. Calculate positions and PnL

    Clients want to see what they hold, what it cost them and how much they’ve made or lost.

    Your system adds up each client’s quantity per asset and applies your cost-basis method, such as first in, first out, to work out realized PnL (profit or loss on what was sold). Book the dollar value of each trade when you record it, so a later price correction doesn’t change last month’s statement.

  8. Show positions and PnL to the client

    Clients check their crypto next to their other accounts, on the screen and on their statement.

    Your app shows each position, its cost and its gain or loss, with current values from the price source you use elsewhere. Unrealized PnL (on what the client still holds) moves with the market, so the statement records the price and time it was taken at.

What to know about streaming client trades

  • History is loaded once per wallet, then kept current without polling.
  • Tables keyed on a primary key take reorg corrections as updates and deletes.
  • Positions and PnL follow your cost-basis method, which takes each buy and sell in order, so they’re a query or job in your database.
  • Goldsky runs the pipeline; you own the database and the PnL logic.

What you control

Your team
  • Take the client’s order
  • Calculate positions and PnL
  • Show positions and PnL to the client
Your providers
  • Custodian

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 track positions and PnL

Track crypto positions and PnL for clients 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