Crypto-as-a-Service for Banks and the Hidden Client-Side Infrastructure Gap

A provider of Crypto-as-a-Service for banks delivers the execution and custody side of a digital asset offering – not the client-side one. A Crypto-as-a-Service provider connects an institution to liquidity, routes orders, and safeguards assets. Areas such as managing individual client accounts, pricing and quoting for those clients, calculating client-level P&L, allocating omnibus-level activity to the individual client, or keeping audit-ready books are typically out of scope. As such, those four areas – pricing and quoting, position and P&L, allocation, and bookkeeping – sit with the bank regardless of which provider it selects.

Our latest insight looks at each of these four gap areas in turn, and how a regulated institution can close them once a Crypto-as-a-Service provider is already in place. For the bigger picture of where Crypto-as-a-Service fits inside a complete digital asset operation, see The Digital Asset Client-Side Gap Every Bank and Broker Discovers Too Late When Outsourcing to a CaaS Provider. This article will examine one part of that picture: the client-side layer itself.

For the broader question of building a digital asset offering beyond CaaS specifically, see our article on How Banks Build Digital Asset Brokerage in 2026.

Why client-side infrastructure is often overlooked in Crypto-as-a-Service projects

Crypto-as-a-Service buying decisions tend to center on the same handful of criteria, including how quickly the provider can go live, which liquidity venues and custodians it connects to, and the regulatory licensing it holds. Those are reasonable things to evaluate first, since they determine whether the institution can launch at all. But they also mean the evaluation happens almost entirely on the street-side of the business.

How the institution will price its clients, bill them, work out what each one owns, and account for all of it rarely makes the vendor scorecard, because Crypto-as-a-Service providers simply don’t deliver this side of the operation. The gap becomes visible only once real clients start onboarding at volume, at which point pricing logic and reconciliation processes that were sketched out informally during the pilot suddenly have to hold up in production, under audit, and at scale – usually with far less runway to fix them properly than the team had during procurement.

The sections below work through the specific questions a team should be able to answer before it signs with a CaaS provider, including how client pricing gets built, what happens to positions and P&L, who is responsible for splitting pooled activity between clients, and how it all gets recorded.

What Crypto-as-a-Service for banks does not solve: the individual client layer

A typical Crypto-as-a-Service scope of service is defined in street-side terms, covering order routing to liquidity venues, execution and fills, custody and settlement of assets, and the regulatory licensing that supports brokerage and custody activity. The provider’s scope ends at the boundary between the institution and its liquidity and custody counterparties.

Everything beyond that boundary, from receiving a client’s order and applying the institution’s own pricing and risk checks to it, to deciding whether it’s worked on an agency or principal basis, and tracking it through to a client-level fill, position, and ledger entry, is what can be termed client-side order management. A Crypto-as-a-Service provider generally has no visibility into this side of operations at all. It simply sees a pooled flow of orders and settlements from the institution; it does not see which client placed which order, what price that client was quoted, or what that client’s resulting position looks like.

That’s a structural gap rather than a maturity gap that a more sophisticated provider could eventually close. A Crypto-as-a-Service provider is built to serve the institution as a single counterparty. It logically follows that individual-client visibility is something the institution must build and maintain itself, since without it, the institution has no independent way to verify that what it tells clients matches what actually happened.

Why pricing, quoting, and fee management cannot be an afterthought

The price a Crypto-as-a-Service provider quotes is what the institution itself pays or receives – not the price its clients see. Turning that into a client-facing quote requires crypto pricing and quoting logic by the institution. The bank or broker’s spread or markup is layered on top, adjusted by client tier, instrument, or order size, and delivered in real time so the client isn’t trading on a stale number.

Fee management sits alongside pricing but isn’t the same thing. Institutions typically need tiered fee schedules by client segment, per-instrument overrides, and the ability to change commercial terms without a development cycle each time. Left unaddressed, crypto fee management tends to rely on manual pricing sheets and ad hoc adjustments made at the point of trade.

The cost of operating in this way might not show up immediately, but it will emerge eventually. A pricing or fee decision that can’t be reconstructed will only hold up until a client asks why they were charged what they were charged, or a regulator asks the institution to demonstrate that its pricing was fair and consistently applied. At that point, defending a manual adjustment won’t cut it. Rebuilding a defensible pricing and fee history after the fact across a growing client base is a far more expensive exercise than building in the controls up front.

Why omnibus-to-client allocation is critical for banks and brokers

Most Crypto-as-a-Service providers operate on an omnibus basis, such that client activity is pooled and settled as a single account at the provider, rather than the provider holding a separate account per underlying client. A single omnibus order might fill at several different prices over the course of a trading session, and it’s the institution’s job, not the provider’s, to work out which client order gets which slice of that fill, at what price. This step – turning pooled, provider-level activity into correctly attributed client-level records – is generally known as post-trade allocation.

A Crypto-as-a-Service provider’s job is done once a trade clears at the omnibus level; it has no further role in dividing that activity among the institution’s clients. If allocation is slow, manual, or error-prone, the consequences land on the institution directly, perhaps in the form of a client statement that shows the wrong position, a reconciliation break between the omnibus account and the sum of client sub-ledgers, or a gap that only surfaces when internal audit or a regulator asks the institution to prove that every unit of pooled activity has been correctly attributed.

This burden doesn’t shrink if an institution works with more than one provider to diversify counterparty risk. In fact, it compounds, since allocation then has to reconcile and combine pooled activity across providers into one coherent set of client positions rather than just one.

The importance of client position and P&L management

Allocation is the process where each trade gets attributed to the right client. What happens next is tracking, which means keeping an accurate, up-to-date record of what each client holds, at what cost basis, and how that position performs as prices move. Effective tracking involves maintaining per-client position data independently and calculating realized and unrealized P&L at the client level, since these are figures that underpin client statements, performance reporting, and the institution’s own revenue recognition.

Where this tends to go wrong is at scale. A handful of clients can be tracked manually, in a spreadsheet, reconciled by hand at month-end. Yet, that approach doesn’t survive growth. As client numbers and trade volume increase, manual position-keeping either requires adding headcount roughly in line with volume, or it starts producing errors, such as a position that’s slightly off, a client statement that doesn’t match what actually happened, or a P&L figure the desk can’t fully explain when asked. Neither outcome is one an institution wants to discover mid-quarter, and both are expensive to fix once they’re embedded in how the business already runs.

How banking-grade bookkeeping supports auditability and compliance

Client pricing, client positions and P&L, and allocation all eventually have to land somewhere in a form internal audit, external auditors, and regulators will accept. That means banking-grade accounting. Double-entry bookkeeping must be applied consistently across client and pooled accounts, with a full, immutable audit trail of every transaction and adjustment.

In practice, this requires digital asset bookkeeping with processes for maintaining a sub-ledger for each client, reconciling it against the provider’s own reporting, and posting it to the institution’s core banking and general ledger systems. However detailed a provider’s own reporting is, it isn’t built to serve as the institution’s books of record for its individual clients – it reports what happened at the provider, not what the institution owes to, or holds on behalf of, each client.

The institutions that get caught out here are usually the ones treating bookkeeping as a manual, after-the-fact clean-up rather than a running system of record. The manual approach will only hold together until the moment it’s tested by an audit, regulatory inquiry, or a client dispute over a statement. At that point, reconstructing an accurate, defensible history from spreadsheets under time pressure is a far worse position to be in than having the sub-ledger already reconciled and ready.

How Wyden Infinity solves the client-side infrastructure gap

Each of the gaps described above – pricing and quoting, position and P&L, allocation, and bookkeeping – maps directly to capabilities within Wyden Infinity, our unified digital asset trade and orchestration layer built for banks and brokers. Wyden Infinity is designed to sit alongside a Crypto-as-a-Service provider, not in place of one, handling the client-side and core operational layer that the Crypto-as-a-Service provider was never scoped to cover.

Specifically, Wyden Infinity provides client-side order management under agency or principal models, real-time client pricing and quoting with embedded spreads and fee logic configurable per client or segment, real-time client position and P&L management, automated omnibus-to-client post-trade allocation, and banking-grade double-entry bookkeeping with a full audit trail into the institution’s core systems.

Because Wyden Infinity operates as an orchestration layer rather than a replacement for the Crypto-as-a-Service relationship, it works with a single provider – or with multiple providers used for diversification – without requiring a separate client-side build for each one.

Crypto-as-a-Service alone vs. “Crypto-as-a-Service + Wyden”

Closing summary

A Crypto-as-a-Service provider gives a bank or broker fast, credible access to execution and custody, but it was never scoped to price a client, track a client’s P&L, allocate omnibus activity down to the individual account, or keep audit-ready client books. Those four responsibilities stay with the institution regardless of which provider it chooses, and are best planned for alongside the Crypto-as-a-Service decision rather than after client volumes have already outgrown manual workarounds. Wyden Infinity is built to be that client-side layer, completing the operating model a Crypto-as-a-Service provider starts rather than competing with it.

If you’re interested in seeing how Wyden can operate alongside your existing Crypto-as-a-Service setup, talk to our experts for an initial business case discussion and platform demo.