One App, Different Financial Systems: What Brokerage as a Service Outsources

A customer sells an investment and asks to withdraw $100. The app shows the sale as complete. The money has not reached the customer’s bank.

For the operator, that is the start of an investigation. The sale could be correctly executed while a separate funding, settlement, verification, or payout step remains open. The next action depends on identifying which obligation is unfinished.

Brokerage as a service changes who performs those steps. To compare the arrangements, follow the accounts and obligations behind the interface.

Choose the operating model before comparing features

Consider three arrangements from the preceding articles.

The first is a local platform offering US stocks through securities brokerage infrastructure such as Alpaca. The second is the workflow I used in treasury at local crypto exchanges: buy tokens from a global LP, transfer them back, and replenish inventory. The third is a local application buying an embedded crypto service with account, custody, or execution capabilities.

These arrangements address different scopes of work. Buying inventory from an LP leaves the local exchange operating the relevant customer-facing systems and replenishment process. A broader infrastructure contract can assign additional functions to a specialist. The scope must be read from the selected model and agreement.

For the examples below, assume a $100 ETF purchase through an eligible securities account and a $100 BTC purchase through an eligible custodial crypto service. They are illustrative purchases, with fees and price changes excluded. The inventory-sourcing alternative remains an operating comparison rather than a claim about how either specific customer trade is fulfilled.

Map the records that establish the balance

A customer’s position, an upstream account balance, and assets held at a bank or custodian can appear in different systems. The operator needs to know how those records correspond.

In a securities arrangement, individual customer accounts and a partner’s omnibus account are different structures. Alpaca’s OmniSub documentation explicitly treats subaccounts as technology records beneath one legal omnibus brokerage account. Additional subaccount detail does not, by itself, create another legal brokerage relationship. Alpaca OmniSub

An embedded crypto provider can also distinguish a customer resource, accounts, and external funding destinations. Payward’s concepts separate user and account resources; an account records balances and activity. A bank account or blockchain wallet used to fund it is another part of the system. Payward account concepts

The operator should be able to trace the app’s displayed $100 position to the account and activity records supporting it. If the app and provider disagree, a customer screenshot alone cannot settle the accounting question. It is evidence of what the interface displayed, which still needs comparison with the underlying transactions.

For a specific arrangement, I would put eight questions on one page:

Function	Question the operating agreement must answer
Customer relationship	Which entity contracts with the customer?
Asset custody	Who holds the asset, and in what account structure?
Execution	Who receives the instruction and establishes the trade?
Funding	Who supplies funds before the next obligation falls due?
Settlement	Which payment or delivery completes which obligation?
Records	Which records support the entitlement shown to the customer?
Exceptions	Who can correct, release, reverse, or investigate the item?
Exit	How could the customer or platform move the relationship elsewhere?

An answer such as “the provider handles it” is too broad for a support case. The provider might execute the trade while the platform still funds an aggregate account or handles customer reporting. The table needs actions and responsible parties.

The screen combines different clocks

Execution, settlement, and withdrawal need their own records.

In the securities example, the ETF trade can execute before the standard settlement date. Most covered US securities transactions follow T+1, with relevant exceptions. A later bank withdrawal is another process. SEC settlement-cycle FAQ

A crypto trade within a custodial provider can update that provider’s ledger without sending a token to the customer’s external wallet. Payward Swaps, for example, distinguishes an accepted transaction being executed from settled completion. A separate external transfer has its own progress and evidence. Payward swap lifecycle

In the direct-sourcing example, an LP purchase can be complete while the tokens are still on their way to the local exchange. The preceding article’s invented replenishment case leaves 400 units available locally while 800 are in transit. The operational question is whether the available 400 can meet the need before receipt. The combined total of 1,200 does not answer that.

Continuous market access does not remove those dependencies. Nor does faster settlement automatically supply funds wherever they are needed. A business can reduce the interval between trade and settlement while still committing cash to several accounts or arranging funding ahead of a cutoff.

Investigate one unfinished withdrawal

Return to the customer who sold and requested $100. Use the following as an illustrative incident, not a report about any named provider.

The application recorded a sale execution. Its customer ledger now displays $100. The withdrawal request timed out, and the support team has no confirmed bank receipt.

First establish whether the $100 is eligible for withdrawal under this account’s rules and completed transactions. Then determine whether the payout request was created upstream. A timed-out response leaves that request’s state uncertain; sending the instruction again can create another payout if the first one already exists and the system does not prevent duplicates.

The investigation should retain the original client reference and retrieve the associated transaction. A trade identifier, a ledger activity identifier, and a payout identifier can refer to different legs. They need to be connected without being treated as interchangeable proof.

Suppose the provider accepted the payout but the local application missed the response. The work is to recover the existing request and its status. Suppose instead the request was rejected because funds were unavailable. The work moves to the account balance, restrictions, and funding path. Those two cases can produce the same customer complaint while requiring different actions.

If a provider record is correct but the local ledger missed an event, recovery concerns the local records. Alpaca’s financial activity documentation describes replay and duplicate handling for that kind of synchronization. A retry policy should respect the documented identifiers and semantics of the actual endpoint being used. Alpaca activity documentation

Support can then give a precise answer: the sale is complete; the payout was accepted under a specified reference; final receipt remains unconfirmed; this team owns the next investigation. That is more useful than repeating the balance displayed on the screen.

“Plug and forget” describes less work, with a supplier to manage

Compared with the buy-transfer-replenish workflow I used, an integrated service can remove substantial operating work. The local team may no longer need to connect every component itself or manage the same physical movement of inventory for that product design.

The remaining work follows the agreement. Customer verification can remain partly or wholly with the platform. zerohash documents both provider-run KYC and a track where the platform performs KYC. Binance’s CAAS offering is gated by its institutional and jurisdictional requirements. These are conditions of a working integration, rather than features that a front-end developer can assume from possession of an API key. zerohash KYC tracks, Binance CAAS availability

The local team also needs to notice changes: a product becoming unavailable to an account, a permission being withdrawn, a funding route changing, or records no longer agreeing. Which of these checks is automated is an implementation question. Who responds when a check fails is an operating decision.

Price the whole arrangement

The cost comparison should cover the service the business is actually buying.

A simple contribution model is customer revenue minus provider charges, funding and payment costs, internal operations, and losses from exceptions. It is a framework for analysis, not an estimate of any provider’s margins. The variables also depend on volume, balances, customer activity, and product scope.

Direct sourcing leaves the business managing inventory purchases and replenishment. An embedded arrangement may replace some of that work with service fees, a revenue share, spread arrangements, or other contractual charges. It can also create funding or collateral needs that differ from the direct-sourcing route. Compare those terms using the same expected activity and stress scenario.

The supplier’s incentives deserve a separate line. Alpaca’s dated customer disclosure identifies revenue from order flow, lending-related activity, and cash. E*TRADE’s crypto service discloses a shared customer commission. Those examples show why the customer trading fee alone cannot explain the commercial relationship. Alpaca Form CRS, E*TRADE crypto disclosures

One application can contain several financial relationships

The market already crosses the stocks-and-crypto boundary in both directions. Kraken announced US securities through Alpaca in April 2025. In June 2025 it announced Alpaca’s integration of Kraken Embed for crypto. E*TRADE’s separate zerohash account supplies another direction of travel. These are specific product relationships, not evidence that every asset inside one application has identical custody or protections. Kraken securities partnership, Alpaca’s Kraken Embed integration

The practical reading exercise is to identify the relationship behind the asset you are buying. Find the contracting entity, custody arrangement, supporting records, withdrawal route, and exception owner. Check the product’s own protection disclosures rather than carrying a securities or bank-account assumption across to another account.

For a team launching a service, I would finish the review with one unresolved transaction. Give it an actual identifier in the test environment, interrupt a response, and ask the responsible team to recover the state without creating a duplicate. Then follow the same transaction through to the permitted destination. The ability to explain that result is part of operating the product.

This is the third article in a three-part series on brokerage infrastructure. The purchases and incident are illustrative. Personal experience refers only to the previously described treasury sourcing workflow. Public product documentation was checked on 25 October 2026.