Goldsky

Pre-signing policy checks for custodians

Talk to our team

What it is

Pre-signing policy checks, also called pre-transaction screening or a transaction policy engine, test each outgoing withdrawal from a custody account against your rules and a risk verdict on the destination wallet before the custodian signs it.

Custody platforms and custodian banks run them because a transfer can’t be called back once it’s signed, so a withdrawal to a listed or high-risk wallet has to be stopped before the signature.

Your custody platform calls a callback handler you host, which runs a task on Goldsky Compose that checks the destination against your list, calls your risk provider for a verdict and returns allow or deny, with each decision recorded; the policy, the provider, the handler and the signature stay yours.

How a withdrawal gets checked before it’s signed

The diagram follows one withdrawal from the customer’s request to the approved transfer settling onchain, and shows who does each step. Your setup may differ.

Withdrawal requestedA customer asks to send funds out

Wallet or custody providerHold for a checkSigning waits for your handler’s answer

Call the policy taskYour handler sends the transfer’s details

ComposeScreen the destinationThe wallet is checked against your list

Screening providerReturn a risk verdictYour risk provider scores the wallet

ComposeAnswer allow or denyYour rule weighs the list and verdict

Wallet or custody providerSign or blockOnly allowed transfers get signed

Funds sentThe approved transfer settles onchain

Goldsky
Your provider

How to run policy checks before signing

Your custody platform holds each outgoing transfer and calls a callback handler your team hosts, which runs a task that you write and Goldsky hosts. The task checks the destination against your list, calls your risk provider for a verdict, applies your rule and returns allow or deny, with every input and output logged.

What you’ll need

Goldsky Compose
A custody platform that calls your handler before signing
A small callback handler service that you host
A sanctions list or risk scoring provider
Your blocklist and transfer policy
A team that reviews denied transfers

Take the withdrawal request
Every check starts with a customer asking to send funds out.
Your app records who asked, the amount, the asset, the chain and the destination wallet, and passes the request to your custody platform. A request without a destination or chain can’t be checked, so reject it before it goes further.
Hold the transfer for a check
The check has to happen before the signature, because a signed transfer can’t be called back.
Your custody platform holds the transfer and calls a callback handler you host with its details before any key signs. Check how your platform treats a late answer: a callback that fails closed, the safe default, blocks the transfer on a deny or on no answer within its time limit, so the whole check has to finish in time.
Pass the request to your policy task
The custody platform expects an authenticated answer in its own format, from a server it trusts.
Your handler checks that the request really came from the platform, sends the transfer’s details to the task and turns the decision into the response the platform expects. Keep it thin, since any delay in the handler eats into the platform’s time limit.
Check the destination against your list
Handled by Goldsky Compose
A wallet on your own blocklist or a sanctions list should be stopped without waiting on anyone else.
The destination is compared with your list in one address format, and a match is enough to deny. The list has to be the current one, so a newly added wallet is blocked from the next request on.
With Goldsky, your handler calls a Compose task’s HTTP trigger, which takes any JSON payload. The task can look the wallet up in a Compose collection that holds your list, which another task keeps current.
Keep your list in a collection (opens in a new tab)
Get a risk verdict on the wallet
A wallet that isn’t on any list can still have links to stolen funds or other risk your provider tracks.
Your risk provider returns a score or verdict and the reasons behind it. If the provider doesn’t answer, your policy needs an agreed outcome, or the check stalls.
Answer allow or deny
Handled by Goldsky Compose
The custody platform needs one clear response it can act on.
Your rule weighs the list check and the verdict, for example denying on any list match or on a score above your threshold, and returns allow or deny with the reason. A reason on every deny lets your team explain the decision to the customer and to an examiner.
The Compose task calls your risk provider with fetch, applies your threshold in TypeScript and returns its decision and reason as the HTTP response, which your handler passes back to the custody platform.
Return a response over HTTP (opens in a new tab)
Keep a record of every decision
Handled by Goldsky Compose
Auditors and customers may ask later why a transfer was allowed or blocked.
Each decision is tied to the request, the list entry checked, the verdict and the rule that applied. A decision with no saved inputs can only be explained from memory.
Goldsky Compose logs every call a task makes with its inputs and outputs, and the task can also write a decision record to a collection keyed on the request ID.
How Compose logs each call (opens in a new tab)
Sign or block the transfer
Only an allowed transfer should get a signature.
Your custody platform signs allowed transfers under its approval policy and blocks denied ones, telling your app which happened. Send each denied transfer to a reviewer, so the customer gets an answer instead of a withdrawal that silently never arrives.
The approved transfer settles onchain
The withdrawal is done once the chain has accepted the transfer and enough blocks sit on top of it.
Once it’s included, the funds are in the destination wallet and the transfer can’t be reversed. If it fails or is dropped, the request needs a fresh check before it’s sent again, because the list may have changed.