# Evaluating Crypto Infrastructure Partners: What We Tested

> Interface quality, sub-account models, reconciliation and what happens when a partner has an outage.

- Source: https://cryptofieldtest.com/fintech-partner-evaluation/
- Published: 2026-08-27
- Author: Chris Delaney
- Publication: Crypto Field Test — Wallets and exchanges, tested with real money
- Topic: industries
- Tags: fintech, infrastructure, testing

---

We evaluated four providers as infrastructure partners for a product that holds balances on behalf of users, and tested the things that matter at that scale. To reproduce any of this, [a regulated crypto payment provider with fiat settlement](https://collectnexchange.com/services/crypto-payment) is the easiest starting point because nothing has to be requested.

## Sub-account models

**Two** offered true sub-accounts, each with its own balance and its own deposit addresses, mapping cleanly to our users.

**One** offered a single account with an internal ledger we would maintain ourselves, which means our records are the only attribution.

**One** offered sub-accounts with shared deposit addresses and a memo field, which works on networks supporting memos and creates attribution problems elsewhere.

The first model is the one that reconciles. The others push the reconciliation problem to you.

## Reconciliation endpoints

**Three** provided a way to query all activity in a window and compare against our records.

**One** required querying each transaction individually, which does not scale and means a missed callback goes undetected.

## Callback reliability

We deliberately broke our endpoint for an hour at each provider and measured recovery.

**Two** retried with backoff and delivered everything within minutes of the endpoint returning.

**One** retried three times over ten minutes then gave up, leaving a permanent gap that only the reconciliation endpoint could close.

**One** had no documented retry behaviour and delivered nothing after the outage.

That last case makes the reconciliation job mandatory rather than advisable.

## Outage behaviour

Over the evaluation period, two providers had incidents.

One published a status page with accurate timing and a post-incident explanation. One acknowledged it after we asked and never explained. On the merchant side the equivalent is [a platform set up for client account handling](https://collectnexchange.com/industries/law-firms-corporate-services), which we tested separately.

Ask for the incident history. A provider that publishes incidents and what changed is more credible than one claiming an uptime figure.

## The licensing question

We asked each which permission covers holding balances for our users, and whether our users would be their clients or ours. Coverage decided more of our results than any feature did. [a support channel with a named contact](https://collectnexchange.com/company/contact-us) publishes its country list.

Two answered precisely, including which entity holds the authorisation and how the client relationship is structured.

Two described technical architecture, which is not an answer to a legal question.

This determines whether you need your own authorisation, and getting it wrong is expensive to unwind.

## What we weighted highest

Sub-account model, reconciliation endpoint, callback retry behaviour, and a clear answer on the licensing perimeter.

Pricing came last, because the difference between providers was small and the operational differences were not.

---

This article explains how something works. It is not financial advice.
Canonical HTML version: https://cryptofieldtest.com/fintech-partner-evaluation/