Evaluating Wallets-as-a-Service (WaaS) Platforms: Institutional Priorities

This is Part 2 of a three-part series on Wallets-as-a-Service (WaaS) for financial institutions.

In Part 1 of this series, we introduced Wallets-as-a-Service (WaaS), defined how it works, and explored the wide range of institutional use cases it supports. In this article, we examine how financial institutions can critically evaluate WaaS providers. We’ll focus on architectural design choices, deployment and control models, regulatory considerations, and the most important functional and security capabilities to look for in a platform.

Why Careful Evaluation of WaaS Platforms Matters

Unlike the world of consumer wallets, WaaS platforms serve as core infrastructure for financial institutions. This means the security, performance, and architecture of the chosen provider can directly impact operational resilience, compliance risk, and even fiduciary responsibility.

Institutions must therefore evaluate WaaS platforms not just on features, but on where the residue of trust remains, governance capabilities, and compatibility with internal systems and policies.

Key WaaS Provider Evaluation Categories

Custody and Key Control Models

Who holds the keys—or more precisely, the key shares—matters. Institutions should ask:

• Is the solution custodial or non-custodial?
• If MPC or TSS is used, how are shares created and distributed?
• Can the institution hold all of their own key shares?
• Is it possible to enforce independent quorum approval?
• How does backup and key recovery work? Can I test it out?

This is foundational. Control over private keys translates to control over funds, and many WaaS solutions still operate on opaque or highly custodial models while being described as “self custody”. Not only do you need full confidence in the key share creation and management process, but also you need to know that your recovery path is viable should the vendor have a broad outage or failure. A dry run of the recovery process when everything is working can give false comfort - will it work all the same when there’s a crowd stampeding for the emergency exit, how quickly can you recover your assets then?

Deployment Architecture

Starting with where the infrastructure runs—vendor-hosted cloud, customer-hosted, or hybrid—has huge implications for risk management, data sovereignty, and regulatory compliance.

• Is the platform multi-tenant SaaS, single-tenant, or deployable on-premise?
• Does it support dedicated infrastructure per client?
• Can transaction signing and policy enforcement be run in a private environment?
• Does the provider expose APIs that allow orchestration without sharing sensitive credentials?

Institutions with strict IT governance or jurisdictional restrictions may require a self-hosted or hybrid option to satisfy internal audit and regulatory mandates. If you rely on material outsourcing agreements then you need to go beyond simple vendor due diligence questionnaires and really get to understand how the vendor hosts the software in their environment and can guarantee security and availability of the system. This approach often leads to coming up against a black box where you must take a leap of faith. For this reason, financial institutions have historically deployed all critical infrastructure locally and reduced the vendor to as minimal involvement as possible. For these regulated firms they simply have a non-negotiable requirement to create and hold all of their private keys, as well as other security critical components such as the policy engine. 

Transaction Policy and Governance Engine

Institutions must be able to enforce granular control over transaction approvals and signing logic:

• Can roles, permissions, and workflows be configured?
• Are multi-user quorum policies supported?
• Is transaction metadata accessible for pre-signing checks?
• Can policies enforce geography, asset type, time-of-day, or amount limits?
• Can policy violations be logged, alerted, and blocked in real-time?

This engine is critical for internal governance, separation of duties, and auditability. Roles and permission sets should not be limited to a handful of coarse templates, they should be highly granular. They should also be created to suit the customer’s own risk framework and satisfy concepts such as the principle of least privilege.  

Auditability, Logging, and Monitoring

Financial institutions operate in environments where audit readiness and traceability are non-negotiable.

• Are all signing events logged immutably?
• Can logs be exported or data piped into other customer side systems?
• Are time-stamped records maintained for all transactions and policy decisions?
• Can abnormal behavior or access violations trigger alerts?

Transparency and verifiability of transaction histories support both internal compliance and external regulatory inquiries. This follows the “write once, ready many” approach to record keeping. This shouldn’t just apply to transactions. Any policy change, environment configuration, or user management should all be immutably logged and retrievable for review. 

Regulatory and Compliance Support

WaaS solutions should not operate in isolation from the broader compliance stack. Look for:

• Travel Rule integration (e.g., TRISA, Notabene, etc.)
• KYC/AML orchestration hooks
• Role-based access control
• Reporting and audit exports
• GDPR and data residency compliance

For institutions operating in multiple jurisdictions, localized compliance tools are increasingly critical. Data sovereignty is often overlooked. If your WaaS solution is vendor side hosted then that can present some tricky hurdles should you need to port your data away at a later date. Or, if you need to ensure data is held within your geographical borders.

Chain Support and Infrastructure Redundancy

Ensure the WaaS platform supports the chains and assets you need—with high availability.

• Are major chains (Bitcoin, Ethereum, Solana, EVM L2s) supported natively?
• Does the provider operate resilient RPC infrastructure?
• Is fallback routing in place for degraded or failing networks?
• Can custom or private chains be added if needed?

This is not just a checklist—it’s an operational continuity issue. Particularly if you are using a multi-tenant SaaS environment, during fast moving markets and high volume of API calls key components can run too hot and ultimately fail. While the security assumptions may remain intact, you want operational resilience built in by design so that you are not minimising the probability of having to follow up with your vendor to complete your own incident report. 

Integration, Modularity, and Extensibility

WaaS is not a standalone system. It must integrate cleanly into your broader architecture, including internal tools, middleware, compliance systems, and orchestration frameworks. To evaluate a provider’s adaptability, institutions should ask:

• Is the API surface well-documented, versioned, and RESTful or gRPC-compatible?
  
• Can WaaS events and transaction states be consumed by orchestration tools or middleware?
  
• Does the system support modular replacement of key components (e.g., KYC provider, signing engine, RPC layer)?

Open architecture ensures long-term flexibility and futureproofing. Self-hosted platforms, in particular, typically offer greater configurability and extensibility than SaaS-based models. That means institutions can avoid the heavy engineering required to reshape rigid SaaS products—engineering work that often leads to deeper vendor lock-in.

By following a top-down approach to risk management, institutions can shape the WaaS solution around their control frameworks and operational model. This avoids the trap of solving one risk while inadvertently introducing five new ones. The architecture should serve your requirements—not force you to compromise them.

Evaluation Checklist Summary

When assessing WaaS providers, institutions should ask:

✅ Is our control of key management complete or infringed on by the vendor?

✅ Is the platform deployable in our environment or dedicated infrastructure?

✅ Can we define and enforce our own transaction policies and governance workflows?

✅ Are audit logs comprehensive, accessible, immutable, and exportable?

✅ Does the platform integrate with our compliance and monitoring stack (e.g., KYC, AML, SIEM)?

✅ Are the supported blockchains sufficient, and is connectivity fault-tolerant?

✅ Can we integrate the platform into our systems without risk of vendor lock-in?

Looking Ahead

The next and final article in this series will explore how Cordial Systems addresses these evaluation challenges through its self-hosted, programmable wallet infrastructure. We’ll examine how Cordial’s architecture supports institutional control, security, and operational flexibility—without third-party dependencies.