The missing tender criterion: standards and interoperability in the selection of blockchain analytics and intelligence tools

Elliptic has published two documents this month that any organisation about to buy blockchain analytics or intelligence capability should read. The technical paper Built for Compliance sets out nine engineering decisions that, in Elliptic’s view, determine whether an on-chain risk system supports fast, accurate and defensible compliance decisions at scale. The accompanying article, 9 questions to ask every provider about on-chain risk, turns those decisions into questions that Elliptic suggests buyers put into requests for proposals and first vendor calls.

The questions are good ones. Whether a provider computes exposure at the moment of screening or serves a stored result, what uptime it actually delivered, how it absorbed its last volume spike, what “fully covered” means when it quotes a number of blockchains, whether a screening follows funds across chains in a single pass, whether it will recognise a new address generated by a sanctioned entity, how it keeps risk scores current, and whether it has tested a full regional failover and can show the evidence. Each of these separates a system that works under pressure from one that only demonstrates well.

Taken together with the Elliptic Standard, published in September, which sets out eight principles for governing agentic on-chain risk, the three documents form the most complete public account to date of what a serious buyer should demand of a provider. And yet, across all three, two words are absent: standards and interoperability. That absence is the subject of this article.

Why the gap matters

The nine questions all share a structure: they ask a vendor to describe and demonstrate its own system, on its own terms. The paper itself concedes the problem this creates. It notes that coverage counts are “commonly inflated”, that a blockchain is sometimes counted because its addresses can be checked against a sanctions list with no transaction history behind it, or because it shares an address format with a chain that is actually indexed. Elliptic’s answer is to publish its own definition of full coverage. That is a reasonable move for one vendor. It does not help a procurement officer who has to compare three bids, each using a different definition, and who has no independent reference against which to test any of them.

The same applies to almost every other criterion. “Comprehensively attributed” data, the first principle of the Elliptic Standard, has no agreed meaning across the industry: what counts as evidence for a label, how confidence is expressed, how a cluster is justified, and whether a third party can reproduce the attribution with the same inputs are all questions each vendor answers privately. Risk scores on a scale of 0 to 10 from one provider are not the same scores as 0 to 10 from another. An entity label that one tool assigns cannot be verified, or even read, by a second tool without manual re-work.

For a compliance team at a cryptoasset service provider, this is an inconvenience. For a public authority, it is a structural problem. A financial intelligence unit, a prosecutor’s office, a police cybercrime unit or a financial supervisor that procures an analytics platform is buying, in effect, the evidential basis for decisions that will be challenged in court or before an administrative tribunal. If the basis for a label cannot be examined independently of the vendor that produced it, the evidence rests on the vendor’s reputation rather than on anything the authority can defend. Contracts end, vendors are acquired, products are discontinued. Case files built on proprietary identifiers, proprietary risk categories and proprietary export formats do not survive those events intact.

This is a concern we have raised repeatedly over the past year: at the Virtual Asset Summit at INTERPOL in Lyon, in the VI3NNA Declaration, and most recently in Tashkent, where the discussion on aligning national digital stacks with global financial corridors kept returning to the same point. Interoperability is not a technical nicety added once the main purchase is made. It is what determines whether the capability an authority buys today is still usable, and still defensible, in five years.

What a tender should ask for

None of this argues against the nine questions. It argues for a further set of criteria sitting alongside them, which a tender for blockchain analytics or intelligence products and services should state explicitly and weight in the evaluation.

The first is evidenced attribution in a documented form. Every label, cluster and risk category that the system produces should carry its evidence and its confidence in a form that the buyer can retain, examine and present without the vendor’s assistance, and that an expert using a different tool can test.

The second is data portability. Case data, annotations, labels, watch-lists and screening histories must be exportable in an open, documented format at any time, and in full at the end of the contract. A buyer that cannot leave is not in a negotiating position when the renewal comes.

The third is interoperability between tools. The reality of a serious investigation is that more than one platform is used, by more than one agency, often in more than one country. Findings produced in one system should be readable in another. This is impossible without common identifiers, common categories and common exchange formats, which no single vendor can supply on its own.

The fourth is independent verifiability of the vendor’s own claims. Uptime, coverage, failover tests and model validation should be evidenced against a reference the buyer does not have to take from the bidder. Elliptic’s paper states that the results of its live failover tests are available to auditors on request, which is the right instinct. A tender should make that a requirement for all bidders, and should name the reference against which the evidence will be read.

The fifth is continuity of expertise. The Elliptic Standard’s eighth principle, that staff must understand how a system works well enough to interrogate and override it, has a procurement corollary. If the training a vendor offers is only training in its own product, the authority’s analysts cannot evaluate the next vendor, or testify about their method in terms a court can follow. Training against a common professional standard should be scored separately from product training.

The opportunity for OBIS

Each of these criteria needs a reference that is open, vendor-neutral and maintained by the community that uses it. That is what the Open Blockchain Intelligence Standards exist to provide. OBIS is a global, open project, promoted and facilitated by Complexity Science Hub, the Blockchain Intelligence Professionals Association and ICI Bucharest, with specifications written in the open on GitHub and published through a draft, public review and publication cycle. Its three focus areas, investigations, forensics and attribution; regulatory reporting and supervision; and open analytics and research data, map directly onto the questions a public-sector tender has to answer and that a vendor’s own questionnaire cannot.

The practical opportunity is simple. A contracting authority that references OBIS specifications in its tender documents obtains, in one move, a common definition of coverage and attribution that every bidder has to meet, an exchange format that makes bids comparable and outputs portable, and a reference against which a bidder’s claims can be checked by someone other than the bidder. Vendors obtain something as well: a stable, published target to build against, rather than a different bespoke requirement from every authority in every jurisdiction. The anti-lock-in argument is not an argument against vendors. It is an argument for a market in which vendors compete on quality against the same yardstick.

Procurement is also where open standards acquire force. A specification that nobody is required to use remains a recommendation. A specification that appears in the technical requirements of a tender becomes a condition of doing business. This is why the OBIS roundtable series, which continues in Frankfurt on 5 November and then in Paris and Warsaw in the spring, has placed public-sector adoption at the centre of its agenda, and why an implementation pilot with national authorities is being prepared for the period following the specifications’ formal launch.

Bucharest, 22 April 2027

The question of how standards and interoperability should be written into tenders for blockchain analytics and intelligence products and services will be discussed with professionals in the sector at the Blockchain Intelligence Forum in Bucharest on 22 April 2027, where OBIS is formally launched. Procurement officers, supervisors, investigators, prosecutors and the vendors themselves will be in the same room, which is where this conversation needs to happen. Elliptic has set out, with unusual clarity, what a buyer should ask of a provider. The Forum is where the sector can agree on what a buyer should be able to verify, independently of any provider, and on the common reference that makes verification possible.

Elliptic’s Built for Compliance paper and the accompanying nine questions are available at elliptic.co. The Elliptic Standard is at elliptic.co/the-standard-for-agentic-on-chain-risk. The OBIS specifications and the roundtable programme are at obistandards.org.