Wallet infrastructure determines how your institution initiates transactions, protects assets, enforces approvals, and produces audit trails, and how much of that your team manages manually. This guide gives banks, regulated exchanges, payment firms, and asset managers a structured, evidence-based way to score wallet infrastructure vendors, so every requirement is backed by a question and a piece of evidence you can verify.
Before you evaluate vendors, decide whether you’re buying wallet infrastructure at all, or building it in-house. This comparison sets the baseline before you score any vendor.
Each step below lists the questions to ask a vendor, what a strong answer looks like, and the evidence to request
before accepting it. Pro Tip: Ask every shortlisted vendor the same questions, and
require the same evidence, so their answers can be compared side by side.
Your wallet infrastructure should support the architecture your business needs today while giving you the flexibility to evolve as products, transaction volumes, and regulatory requirements change.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Does the platform support MPC, Multi-Sig, and HSM? | All three available on one platform, switchable per wallet, with no migration required to move between them. | Architecture document; live demo of each model in a sandbox environment. |
Can keys stay inside our own infrastructure, or are they held by the vendor? | Yes, HSM-backed deployment is available with customer-held key material. | Deployment topology diagram; HSM vendor compatibility list. |
Which security certifications does the platform hold? | CCSS Level 3 (Full System), SOC 2 Type II, ISO 27001, and ISO 27701. | Current certificates with issue and expiry dates; auditor name. |
Is there independent penetration testing and security auditing? | At least annual, performed by a named third party, with a remediation-tracking process. | Executive summary of the latest test; remediation closure log. |
What is the vendor’s approach to incident disclosure and response? | A documented, time-bound disclosure policy with defined severity tiers and client notification commitments. | Incident response runbook; public trust-centre or security disclosure page. |
Wallet infrastructure needs to fit your existing technology and operating environment, and let you change how it’s deployed as you grow, without rebuilding your digital-asset stack.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Does the platform offer cloud, private cloud, on-premise, and dedicated SaaS deployment? | All four models available, on the same underlying platform, without a re-implementation. | Deployment architecture options document; reference client per model. |
Can the platform support customer-facing wallet infrastructure if the business expands? | White-label and embeddable wallet infrastructure is available without a separate product line. | API and SDK documentation; example of a live customer-facing integration. |
Does the platform support both self-managed and managed operating models? | Institutions can choose to operate wallets themselves or hand day-to-day operations to the vendor’s managed service. | Managed-service SLA and scope-of-work template. |
Can the platform scale without requiring a migration? | Institutions can move between deployment or operating models on the same platform, without re-onboarding. | Case study or reference of a client migration between models. |
Is HSM-backed deployment available for institutions with hardware key requirements? | Dedicated HSM deployment, including on-premise, is available as a first-class option. | HSM deployment guide; supported hardware list. |
Institutional wallet infrastructure must provide more than transaction execution. It needs to enforce how transactions are initiated, approved, and executed across teams and wallets.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Can you configure multi-tier approval workflows tailored to your organisational structure? | Approval chains configurable by wallet, user, role, and transaction type, with no engineering required to change them. | Live policy-builder demo; sample approval-workflow configuration. |
Does the platform support maker-checker controls and role-based access? | Native maker-checker enforcement with granular, role-based permissions. | Role and permission matrix; access-control documentation. |
Are address whitelisting, spending limits, and quorum controls available out of the box? | Yes, without add-on modules or separate procurement. | Product documentation showing each control configured. |
Can policies be customized per wallet, per user, and per transaction type? | Policy engine applies rules at each of these levels independently and in combination. | Policy configuration walkthrough. |
Is there a full audit trail for every transaction and approval action? | Immutable, timestamped audit log covering every action, exportable for regulators and auditors. | Sample audit export; retention policy. |
Compliance should be part of the transaction workflow itself. Institutions should not have to build separate compliance processes around their wallet infrastructure.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Does the platform have native AML and KYT integrations, not just third-party connectors? | Compliance providers embedded directly into the transaction flow, not a bolt-on integration requiring separate configuration. | Architecture diagram showing where screening happens in the transaction flow. |
Is Travel Rule compliance built in and customisable by jurisdiction? | Native Travel Rule support with rules configurable by jurisdiction and threshold. | Named Travel Rule partner; jurisdiction-specific rule-set documentation. |
Does the platform support transaction screening and real-time risk scoring? | Every transaction pre-screened before execution, with risk scores visible to approvers. | Sample risk-scoring output; screening provider name. |
Are compliance workflows embedded into the transaction flow, not bolted on? | Compliance checks are a required step in the approval workflow, not a parallel process. | Workflow diagram; policy configuration showing compliance gates. |
Does the vendor have experience supporting institutions across the jurisdictions in which you operate? | Named clients or verified categories of clients operating under the same regulatory regime. | Reference list by jurisdiction or region. |
At scale, manually managing wallets, balances, transaction retries, and network costs creates operational overhead and increases the risk of errors. A robust wallet infrastructure platform should provide an automation layer that enables teams to operate wallets efficiently across high-volume workflows.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Does the platform automate wallet sweeps, refills, and asset consolidation? | Configurable, rules-based automation with no custom engineering required. | Automation-engine documentation; sample sweep/refill configuration. |
Is there a gas fee optimisation mechanism to reduce transaction costs? | Automated fee optimisation applied by default, with reporting on savings. | Fee-optimisation methodology; before/after cost data. |
Does the platform automatically retry failed transactions? | Configurable retry logic with alerting on repeated failures. | Retry-policy documentation. |
Can treasury workflows be automated without custom engineering? | Workflow builder or configuration UI, not a professional-services engagement. | Product walkthrough of a treasury automation. |
Are operational alerts and mobile approvals available for on-the-go management? | Push and mobile approval available for time-sensitive actions. | Mobile app or approval-flow demo. |
Wallet infrastructure becomes significantly more valuable when it can be integrated directly into the products, platforms, and workflows your business already operates. An API-first architecture enables businesses to build digital-asset capabilities without developing wallet infrastructure, transaction orchestration, and associated controls from the ground up.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Does the platform provide APIs for wallet creation and management? | Full lifecycle available via API — creation, management, and decommissioning. | API reference documentation. |
Can transactions be initiated and signed programmatically? | Yes, with the same policy and approval controls enforced as through the UI. | Sample API call and response; policy-enforcement confirmation. |
Are wallet and transaction data accessible through APIs? | Real-time and historical data available via API, not just export or reporting UI. | Data API schema and sample payloads. |
Does the platform support role-based API access? | API keys scoped by role and permission, mirroring UI access controls. | API key management documentation. |
Can wallet infrastructure be embedded into customer-facing products? | SDKs or white-label components available for embedding. | SDK documentation; example customer-facing implementation. |
Is comprehensive API documentation available? | Public, versioned documentation with sandbox access. | Link to live developer documentation and sandbox credentials. |
This step determines whether you can trust a vendor beyond day-to-day operations: what happens if they fail, how they handle a disaster, where your assets actually sit, what’s insured, whether they hold up under the rules of your jurisdiction, and what you’re actually paying for.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Can we recover our assets without the vendor, and is there a documented exit plan? | A tested self-recovery procedure, key escrow or equivalent, and a written exit plan independent of vendor cooperation. | Exit-plan documentation; evidence of a tested recovery drill. |
What are the platform’s disaster recovery and business continuity commitments? | Stated RTO and RPO, with the date of the last DR test and evidence it was actually run. | DR/BC policy; latest test report and date. |
How is client asset segregation handled, and is regulated custody available where required? | Segregated (not omnibus) client asset structures by default, with a regulated or qualified custody option where the jurisdiction requires one. | Segregation policy; custody entity name, licence, and jurisdiction. |
What insurance coverage applies to assets under management? | Named insurer, defined coverage type and limits, with exclusions disclosed upfront. | Insurance certificate or policy summary. |
How does the platform align with the regulatory regime in each market we operate in? | Named regulation and jurisdiction. For example MiCA and DORA in the EU, MAS DTSP in Singapore, VARA in the UAE, not a generic compliance claim. | Jurisdiction-by-jurisdiction regulatory mapping. |
What is the commercial model, and what triggers a price change? | Transparent pricing structure, disclosed cost drivers, and a stated implementation timeline to go live. | Pricing schedule; implementation timeline with milestones. |
Wallet infrastructure becomes part of your technology stack. The vendor therefore needs to demonstrate the stability, support, and product investment required to operate as a long-term infrastructure partner.
Question to ask | What a strong answer looks like | Evidence to request |
|---|---|---|
Is the platform trusted by institutions in regulated markets across multiple countries? | Named or verifiable client base across more than one jurisdiction, not a single-market track record. | Client references by region or category; case studies. |
Does the vendor have a dedicated regional support team in your operating markets? | Local support presence, not a single global queue. | Support team structure; escalation contacts by region. |
What are the SLAs for support and incident response? | Contractually guaranteed response and resolution times, tiered by severity. | SLA schedule in the master services agreement. |
Is the platform actively investing in product development and new capabilities? | Visible release cadence and roadmap, not a frozen feature set. | Changelog or release notes; product roadmap. |
Does the vendor have a transparent trust centre and security disclosure policy? | Public-facing trust centre with certificates, subprocessors, and disclosure policy. | Link to live trust centre. |
Every institution should work through all eight steps. Where you should spend the most scrutiny depends on what you do.
The table below shows how Liminal addresses each of the criteria covered in the eight steps above.
A structured evaluation using a table-based scorecard typically takes four to eight weeks, covering vendor questionnaires, sandbox testing, security and compliance review, and legal/commercial negotiation. Timelines extend when multi-jurisdiction compliance needs separate sign-off.
At minimum, look for SOC 2 Type II and ISO 27001. CCSS (CryptoCurrency Security Standard) Level 3 and ISO 27701 (privacy) are stronger signals for institutions handling regulated data. Ask for current certificates with issue and expiry dates, not just a logo on a website.
MPC (multi-party computation) splits a key into shares across parties so no single share can sign alone. Multi-sig requires multiple independent keys to authorise a transaction on-chain. HSM (hardware security module) stores keys in certified, tamper-resistant hardware. Institutions increasingly want a platform that supports all three, switchable per wallet, rather than being locked into one.
Building gives full control but takes years to reach production maturity and carries a permanent engineering cost, including keeping pace with new chains and regulatory changes. Buying from a platform reaches production in weeks and shifts regulatory adaptation to the vendor, while still letting the institution retain control of key material. Most institutions buy the infrastructure layer and differentiate on top of it.
This depends on whether the institution retained control of key material and whether the vendor has a documented, tested exit and self-recovery plan. Ask every shortlisted vendor for their exit plan, key escrow arrangement, and evidence of a tested recovery drill before signing, not after.
Ready to Evaluate Liminal Against Your Requirements?
Book a Personalised Demo
