Flow of funds and responsibilities
Who holds the money at each step, who is the regulated party, and who answers for what. Written for a platform's compliance, legal and finance reviewers.
The short version
- SET never holds customer money. SET is software: it onboards customers, instructs movements and keeps the ledger.
- A licensed infrastructure provider holds it, for the minutes or banking days a conversion takes. The provider holds the licences and performs verification, accounts, conversion, custody and payouts.
- A platform stays out of the flow of funds unless SET has reviewed that platform and switched platform funds on for it (Platform oversight).
- Each merchant or payee is verified in their own name and is paid into their own bank account or their own wallet.
The parties
| Party | Role |
|---|---|
| Payer | Whoever pays the merchant or payee: a customer's bank, or a wallet |
| Platform | SET's customer. Calls the API for its merchants or payees. Verified by SET (KYB) |
| Merchant or payee | The person or business being paid. Verified individually. Owns the destination bank account or wallet |
| SET | Software and compliance programme. Instructs the provider; records every outcome from the provider's signed events |
| Licensed provider | The regulated party. Holds funds in transit, converts, and pays out |
| Bank rail or blockchain | Carries the payment in and out |
Where the money is, step by step
SET API way 1: collect by bank, settle to a wallet
| Step | What happens | Who holds the money |
|---|---|---|
| 1 | The payer sends a bank payment to an account in the merchant's name | The payer's bank, then the provider |
| 2 | The provider converts it to a stablecoin and withholds the fee | The provider |
| 3 | The stablecoin arrives in the merchant's own wallet; SET confirms it on chain | The merchant |
SET API way 2: collect in stablecoin, settle to the bank
| Step | What happens | Who holds the money |
|---|---|---|
| 1 | The payer sends a stablecoin to the merchant's Cash-Out Address | The provider, on receipt |
| 2 | The provider converts it to currency and withholds the fee | The provider |
| 3 | The provider pays the merchant's own bank account | The merchant's bank |
SET API way 3: collect by bank, settle to the bank
Way 1 followed by way 2: a bank payment into an account in the merchant's name is converted, sent to the merchant's Cash-Out Address, converted back and paid to the merchant's bank. The provider holds it throughout; SET's fee is taken once.
SET Direct Deposit
| Step | What happens | Who holds the money |
|---|---|---|
| 1 | The platform pays USDC from a wallet it registered to the payee's Cash-Out Address | The platform, then the provider |
| 2 | SET reads the sender on chain and names the platform as originator (Travel Rule) | The provider |
| 3 | The provider converts it and pays the payee's own bank account | The payee's bank |
With Payable Email, the platform first pays a wallet only that payee can unlock. The payee holds the money there and moves it to their own Cash-Out Address themselves.
Payouts from a custodial wallet
A verified customer's custodial wallet is held by the provider, never by SET. A payout leaves it only on that customer's key or signed-in request, and goes to a recipient the customer named.
Fees
- The provider withholds SET's fee from each movement when it converts, and pays it to SET. The customer receives the net amount, and every answer and event states the fee.
- A platform's share of SET's fee, where its contract has one, is paid to the platform monthly by SET from SET's own funds.
- The platform's money and its merchants' money are never mixed with SET's fees.
Who answers for what
| Responsibility | Provider | SET | Platform |
|---|---|---|---|
| Licences for money transmission and custody | Holds them | Holds none; is software | Its own, where its business needs any |
| Identity verification of each customer (KYB, KYC) | Performs it | Collects it, adds its own risk rating and screening | Its own programme, separately |
| Sanctions screening | Its own | Every customer, owner and counterparty SET learns of | Its own customers |
| Travel Rule data | Receives it | Builds it, and refuses a movement that lacks it | Names each payer it can identify |
| Holding funds in transit | Yes | Never | Never, unless platform funds are on |
| Conversion and bank payout | Executes | Instructs | Asks through the API |
| The record of each payment | Its own | The ledger, events, statements and exports | Reconciles from SET's records |
| Transaction monitoring and reporting | Its own | Under SET's programme | Under its own |
| Returned and failed payments | Returns the funds | Records the outcome and tells the platform | Tells its merchant or payee |
| Tax reporting to payees | No | Supplies year-end totals; files nothing | Decides, collects forms, files |
| First-line support for merchants and payees | No | Supports the platform | Yes |
SET's programme does not rely on a platform's programme, and a platform's does not rely on SET's (Compliance programme).
When something goes wrong
- A bank returns a payout. The provider returns the funds to the return address or wallet the merchant or payee controls. The payment moves to
returnedand the platform receives the event. - A deposit must go back. A bank deposit can be returned to its sender by API (Returning deposits).
- A payer cannot be identified. The movement waits for Travel Rule data; it is not released on a guess.
- A Direct Deposit comes from a wallet nobody registered. It is recorded as
unknown_senderand credited to no platform until one proves the wallet is its own. - SET is unavailable. A payment the provider has accepted still completes. SET's ledger catches up from the provider's signed events when it returns (Availability and support).