Buying Tokens Abroad or Buying the Infrastructure: Crypto Behind the App

When I worked in treasury at local crypto exchanges, I sourced liquidity from global liquidity providers. I bought tokens, brought them back to the local exchange, and replenished inventory.

That required more operational work than connecting to an integrated service. The local regulatory burden at the time was why we used that approach. This is my experience of the constraints then; it does not establish what a particular exchange can offer under today’s rules.

I think of an integrated service as closer to “plug and forget” by comparison. A supplier can package account management, execution, custody, and other functions that a local operator would otherwise have to connect and manage. There are still funding commitments, records to reconcile, and customer problems to resolve.

To understand the difference, start with the work involved in getting tokens where they are needed.

Buying liquidity leaves a transfer to complete

A liquidity provider, or LP, supplies executable buying and selling interest. In the workflow I described, the local exchange purchases tokens from an external source and brings them into its own inventory.

The purchase and the replenishment have different completion conditions. A purchase record establishes the trade. The local operating team also needs to establish that the tokens have arrived and are available at the destination.

That raises questions about payment, withdrawal permissions, network selection, deposit processing, and accounting. The exact sequence depends on the arrangement with the LP. Those details should be established from that arrangement rather than inferred from the phrase “we bought the tokens.”

An embedded infrastructure service operates at a broader level. It can supply customer accounts and ongoing custody or transaction services alongside access to liquidity. Purchasing tokens from an LP does not, by itself, buy all of those capabilities. A local exchange might use both kinds of supplier for different purposes.

Purchased inventory can still be unavailable locally

Consider a fictional token inventory. The numbers below illustrate accounting states; they are not records from my former employers, an LP, or an exchange.

The local exchange starts with 1,000 units available for the modeled use. A net outflow consumes 600 units. Treasury buys another 800 from an LP and initiates the transfer. While the transfer is pending, local availability remains 400. Once the destination confirms receipt and the units are released for use, availability rises to 1,200.

Event	Available locally	Replenishment in transit
Opening inventory	1,000	0
Net local use of 600	400	0
800 bought and sent; receipt pending	400	800
800 received and made available	1,200	0
Further net local use of 500	700	0

“Available” has a deliberately narrow meaning here: units released for the modeled local purpose after any relevant restrictions and commitments. The chart does not calculate customer liabilities, regulatory reserves, or total assets. Net local use is a model input; a customer trade alone need not reduce an exchange’s aggregate wallet balance.

An aggregate total that adds those two columns would hide the immediate operating constraint. If the local exchange needs 700 available units before receipt, the modeled shortfall is 300. The purchase may be complete while the local requirement remains unmet.

The next action depends on the state of the transfer. Has the LP released it? Is it broadcast? Has the destination credited it? Has it passed the checks needed for local use? Buying another 800 without answering those questions could leave the exchange with excess inventory after both transfers arrive.

Binance offers more than one integration model

Binance is a valid example of crypto infrastructure supplied to other businesses. Its current developer documentation calls one offering Crypto-As-A-Service, or CAAS. It describes a partner using Binance’s backend for customer subaccounts, wallet functions, trading, and related services. Availability depends on institutional onboarding, jurisdiction, Binance entity, and the approved commercial arrangement. Binance CAAS overview

In the documented CAAS structure, end users sit under the partner’s master account. The partner builds the customer experience and connects its backend to Binance. The integration guide describes creating a subaccount, completing KYC, issuing its permitted API credentials, funding it, and trading. KYC approval gates creation of the trading key. CAAS integration guide

The withdrawal route is revealing. That guide says deposits can reach a subaccount, while an external withdrawal goes through the master account after an internal transfer. A customer balance and the account allowed to send an external payment can therefore be different parts of the structure. Entity-specific requirements must also be checked. CAAS withdrawal guidance, CAAS FAQ

Binance separately documents OMS Toolkit for software connecting through end users’ existing Binance API keys. OMS means order management system. This arrangement adds trade tagging, analytics, reporting, and applicable rebate attribution to connected trading software. It should be distinguished from CAAS’s embedded account and custody backend. OMS Toolkit

This is why a trading API is insufficient evidence that a business has outsourced its whole operating stack. One integration may manage newly created customer subaccounts. Another may let a software product send instructions to accounts customers already hold at the exchange.

The infrastructure suppliers also use one another

Alpaca and crypto infrastructure are already connected. Kraken announced in June 2025 that Alpaca integrated Kraken Embed into its Broker API to expand crypto capabilities for downstream partners. That is evidence of a specific integration, not a routing map for every current Alpaca crypto transaction. Kraken’s Alpaca announcement

Current Payward Services documentation describes infrastructure built on Kraken operations. Its trading offering includes execution, custody, and settlement inside a partner’s application. The legacy Embed naming and current documentation should be read with their dates and product scopes intact. Payward introduction, trading offering

Payward also distinguishes a user resource from an account holding balances and activity. A provider account identifier does not automatically identify an external bank account or a unique blockchain wallet. A useful diagram should draw those separately. Users and accounts

Its Swaps documentation supplies a concrete transaction lifecycle. An offered quote can expire. Acceptance leads to an asynchronous executing state; executed means the swap has settled in that service. Failed and expired outcomes also exist. That trade-settlement state should not be interpreted as confirmation that a separate bank payout or blockchain withdrawal has arrived. Payward Swaps

A traditional investing brand can embed crypto too

ETRADE’s crypto offering supplies another example. Its disclosures describe a separate, non-brokerage account in the customer’s name at zerohash, outside Morgan Stanley. The linked brokerage account supplies buying power, with cash automatically swept to settle crypto transactions. The disclosed 0.50% crypto commission is charged by zerohash, with a portion paid to ETRADE. E*TRADE crypto account and fee disclosures

The same page states that Morgan Stanley does not transact in or custody those digital assets and that the crypto is not FDIC insured or SIPC protected. Incoming crypto transfers were still described as coming soon when checked. The customer’s ability to buy inside an app therefore does not establish an unrestricted ability to move tokens into or out of that particular service. E*TRADE product scope and protections

Compliance arrangements can vary within a supplier’s business. zerohash’s KYC-status documentation distinguishes its own KYC-as-a-Service track from a vendor-reliance track in which the platform runs KYC. A supplier offering compliance services does not establish that every partner has delegated the same checks. zerohash KYC documentation

Less operating work changes the dependencies

The comparison with my treasury workflow becomes clearer at this point. Sourcing tokens externally left us with a transfer and local replenishment process to complete. An integrated provider can package more of the account and transaction lifecycle together, reducing the number of components the local team has to operate directly.

The resulting dependencies still need names. Who must fund which account? Who can authorize an external transfer? Which party has the customer verification decision? Which records support a balance shown in the local app?

The business model follows those choices. Binance documents partner revenue-share and approved markup arrangements; Payward advertises supported fee models; the E*TRADE example discloses sharing a customer commission. These mechanisms should be evaluated under the actual commercial agreement rather than a universal assumption about how crypto brokers earn money. Binance markup documentation, Payward trading

For an operator choosing a route, regulation belongs alongside cost and convenience. In my experience, local requirements shaped the decision before we could enjoy the operational convenience of a broader service. Another business, period, or jurisdiction can produce a different answer.

Before calling an integration ready, follow one customer request through to money or tokens reaching the permitted destination. Record the checks, account movements, and responsible organization at each step. That exercise shows how much work the service has taken on and where the local team still needs an operating process.

This is the second article in a three-part series on brokerage infrastructure. Personal experience is limited to the sourcing workflow described above. Numerical examples are invented. Provider documentation and product scope were checked on 25 October 2026.