Treasury Architecture for Platforms: The First Decision Is Whose Account the Money Lands In
Platforms usually begin payment selection with which provider is cheapest, which channels it supports and how hard integration is.
That starting point is one step too late. Everything downstream is fixed by an earlier question: whose account the buyer's money lands in first.
That one decision locks four things simultaneously: who is eligible to accept the money (onboarding), where funds rest along the chain (fund path), who invoices whom (documentation), and in which jurisdiction tax is filed (tax). All four must be mutually consistent, and none of them can realistically change after launch - changing one means rebuilding the system.
1. Four treasury architectures
1.1 Platform's own entity collects directly
Buyer payments land in the platform's corporate account; the platform then pays sellers on a settlement schedule and keeps the commission.
It is the most intuitive approach and the riskiest. In substance it creates a pool where the platform takes money first and distributes it to third parties afterwards, which in most jurisdictions is a licensed activity; when misappropriation, an implosion or a mass refund dispute occurs, civil liability is the least of the platform's problems.
Its valid conditions are narrow: the platform is the only seller (largely first-party, with occasional third-party supply), or the split recipients are very few and all related entities. A multi-seller marketplace using it is effectively betting that nobody looks closely while volume is small.
1.2 Licensed split settlement
Money never enters the platform's account. A licensed payment institution splits it to each seller at clearing according to split instructions, and the platform receives only its commission.
This is the cleanest structure for marketplaces: the platform does not touch funds, so in principle no pool exists. The cost is three "depends on": which markets and currencies the institution supports, what KYC it requires for each seller, and how finely split rules can be expressed - per order, per line item, per percentage, with fee allocation.
Domestically this maps to the service-provider model, which has relatively consistent rules. Cross-border has no such consistency; every market needs a separate answer to "can a local licensed institution split to multiple sellers".
1.3 Platform as merchant of record
The platform becomes the legal seller to the buyer: it collects, invoices, carries sales tax and chargeback liability, then settles with sellers under agreed terms.
This moves tax complexity inside the platform, which is very seller-friendly and is the common shape for digital goods and standardized SaaS. But it has an often-ignored precondition: merchant of record requires substantive control over the goods and the pricing. On a marketplace where sellers set their own prices, ship their own goods and handle their own after-sales, the platform carrying tax and chargeback liability is an asymmetric arrangement that is awkward in practice.
The test reduces to one question: are you selling your goods or someone else's. The former suits merchant of record; the latter does not.
1.4 Custody accounts and delegated payouts
Funds enter a regulated custody account; the platform issues payment instructions without holding funds itself, or a bank or licensed institution pays sellers on its behalf.
This structure dominates large-ticket, B2B and situations where you must demonstrate fund segregation to a regulator or investor. Cost and onboarding barriers are higher, but "the money is not the platform's" is precisely the value.
2. The four things this decision locks
Onboarding. Who may accept the money: whether the platform itself holds a licence or qualification, or must operate through a licensed institution. Get this wrong and the risk grows with the business.
Fund path. Where funds rest mid-chain: the platform account, an institution's safeguarding account, or a custody account. Each implies a completely different reconciliation and audit regime.
Documentation. Two invoices must be designed separately: who invoices the buyer (platform or seller), and who invoices the platform (the seller invoicing commission, or the platform invoicing a service fee). If the documentation does not match the fund path, finance cannot explain the books.
Tax. Especially cross-border: sales tax in the buyer's jurisdiction, income tax in the seller's, and permanent-establishment analysis in the platform's own. Three separate filing obligations.
3. The three layers of multi-currency pooling
Once a platform goes cross-border, currency cannot be handled as a "supports multi-currency" feature checkbox. It splits into three layers:
Pricing currency: the currency on the price tag, set by market and merchandising.
Settlement currency: what the buyer actually pays in, and what the acquirer clears in. It may differ from the pricing currency because of localization requirements.
Payout currency: what the seller ultimately receives.
When the three differ, FX loss occurs on every conversion, and the more conversions the greater the leakage. Worse is the reconciliation basis: order amount, clearing amount, settlement amount and payout amount are four numbers on different rates at different moments, and any rate movement makes "total order value does not equal total seller payout".
The fix is to record the exchange rate as an explicit field on every movement, rather than recomputing it each time. Differences then stay explainable and auditable.
4. Why cross-border is harder than domestic
Domestic platform splitting is comparatively tractable because a service-provider model exists with consistent rules, plus a clear red line - whether money passes through the platform's own account is the test for unlicensed payment handling.
Cross-border has none of that consistency.
First, no unified split rules. Every market's licensed institutions answer differently on whether they can collect and pay on behalf of others, split to multiple sellers, and whether split recipients need a local entity.
Second, seller onboarding requirements vary widely. Some markets require a local tax ID, some a local bank account, some a local entity. A platform maintains a separate onboarding ruleset per market.
Third, source-of-funds and purpose scrutiny is tighter. Cross-border movement is itself subject to FX controls, and platform collection-and-disbursement is easily read as a cross-border transfer, requiring additional compliance explanation.
Fourth, attributing refunds and chargebacks is harder. One order can involve a platform, a seller, a buyer and two jurisdictions; who absorbs the loss and whose balance is debited must be written into the agreement in advance, or every dispute becomes an ad hoc ruling.
5. A decision checklist
Answer each of these before signing; if the answers conflict, the architecture is not yet settled.
What is the platform's role - seller, channel or intermediary; must funds pass through the platform account; if so, what qualification does the platform hold; which party invoices which on both invoice lines; who performs seller onboarding and to what standard; how granular must split settlement be - order or line item; whose balance absorbs chargeback losses; what are the three currency layers; and how are in-transit funds and reserves handled at termination.
For the trade-offs and the wider layering see the seven layers of a payment stack; for domestic multi-channel access and the service-provider model see aggregated payments and split settlement; for the entity and tax decision see cross-border seller entity structure; for where merchant of record applies see merchant of record platforms; for float and reserve modelling see rolling reserves and float. More payment options are listed under the payment category.
Source: 16IDC original. Licensing, fund custody and tax filing requirements follow local regulation and the terms of the licensed institutions involved.