Open Blockchain Intelligence Standards

Blockchain intelligence is transitioning from an emerging field into an established professional domain, used by investigators, prosecutors, supervisors, and researchers in high-stakes settings (e.g., criminal proceedings, supervisory enforcement, peer-reviewed research). The infrastructure that domain depends on has not made the same transition. Data formats vary between platforms, identical concepts carry different names, foundational computations follow divergent approaches, and findings produced in one ecosystem are difficult to verify or reuse in another.

OBIS develops open, vendor-neutral specifications to close that gap, in public, with anyone who wants to contribute.

About#

OBIS is a community effort, not an institution. Drafts are developed in the open on GitHub. The process is modelled on the IETF and W3C (public drafts, defined review cycles, no membership tiers, no certification business), but the organisational form is intentionally light: there is no board, no chartered membership, and no application to join. OBIS organises standards around concrete use cases rather than abstract layers, because the gaps that matter most appear at the boundary between organisations doing similar work with incompatible tools.

OBIS is currently an unincorporated open community project. Incorporation as a non-profit standards organisation is planned and will be undertaken once the early body of work and contributor base warrant it. Until then, the project operates without legal personhood: contributions are made directly to the public specifications under the licenses described on the License page, and the project holds no funds, assets, or contractual obligations.

OBIS is not a certification scheme, an industry lobby, or a vendor consortium. It is a body of open specifications developed in public by whoever is willing to contribute.

Researchers and practitioners articulated the motivation for this work in detail at the 9th Global Conference on Criminal Finances and Cryptoassets and elsewhere in the field. OBIS is now the venue for turning that motivation into specifications.

Focus areas#

Three use-case domains anchor the first work cycle. Each is grounded in a concrete, documented interoperability problem.

A fourth area, compliance and sanctions screening, is intentionally out of scope at launch. That space is densely commercial and well-served by existing vendor formats. OBIS’s leverage is elsewhere.

Relationship to existing work##

OBIS specifications are designed to sit alongside the existing body of work in this space, not to replace it. Several instruments and reference works define the field that OBIS specifications operate within:

• FATF Recommendations and guidance, in particular Recommendation 15 on virtual assets and Recommendation 16 on the Travel Rule, set the international policy framework. OBIS does not produce policy and does not interpret FATF guidance; it produces technical artefacts that implementations of policy can build on.
• EU instruments including MiCA (Regulation (EU) 2023/1114), the recast Transfer of Funds Regulation, and EBA reporting frameworks define obligations and reporting expectations for entities operating in the EU. OBIS specifications in the regulatory-reporting focus area are intended to be compatible with these obligations and to reduce the integration cost of meeting them; they do not replace or reinterpret them.
• IVMS101 is the established data standard for originator and beneficiary identity information accompanying VASP-to-VASP transfers. It is a transmittal standard, not an attribution standard. OBIS attribution work (e.g., OBIS-0003) operates on a different segment of the workflow and does not subsume IVMS101.
• INTERPOL DW-VA-Taxonomy is a widely-referenced taxonomy for darkweb and virtual-asset activity. OBIS taxonomies in this area draw on it as prior art and aim to remain compatible where the underlying concepts overlap.
• National supervisory frameworks vary by jurisdiction. OBIS specifications are designed to be referenceable by supervisors that choose to adopt them, without prescribing adoption.

OBIS is not a substitute for any of the above. Its leverage is in the technical layer beneath them, where the absence of shared formats and vocabularies currently imposes a cost on every party operating across organisational and jurisdictional boundaries.

Process#

OBIS documents progress through three states: Draft, Public Review, and Published. Drafts are developed in the open on GitHub. A draft reaches Public Review only after rough consensus has emerged among contributors; it reaches Published only after a public comment period has closed and substantive objections have been addressed.

The full process is specified in OBIS-0001: OBIS Document Lifecycle, currently in Draft.

Get involved##

OBIS is developed in the open. Anyone interested in the work is welcome to follow it, comment on drafts, or contribute.

• Drafts and discussion: github.com/obi-standards. Public development of all specifications. Anyone with a GitHub account can open issues, comment on drafts, and submit pull requests. No application or membership is required.
• Email: info@obistandards.org. General correspondence about the project.
• Written commentary on drafts (institutional channel): Institutions that prefer not to engage via GitHub — including supervisory bodies, FIUs, government agencies, and other organisations whose internal processes do not accommodate public pull-request workflows — may submit written commentary on any current draft or document in Public Review by emailing info@obistandards.org with the subject line Commentary: OBIS-NNNN. Commentary received this way is treated equivalently to commentary received via GitHub: it is acknowledged publicly, considered in the editor’s response, and recorded as part of the review record. Senders may request that the institutional affiliation be recorded without naming the individual signatory.

Why participate#

OBIS is open to anyone interested in the work. Different kinds of organisations and individuals have different reasons to engage, and different forms of engagement that suit them. The following framings are not membership categories — they are descriptions of how each audience typically relates to the work.

Tool providers (blockchain analytics platforms, forensic tooling, on-chain data vendors). OBIS specifications reduce the per-customer integration cost of supporting cross-organisation exchange. Vendors retain proprietary value in the data, attribution methods, and analytical capabilities they produce; OBIS standardises only the interchange formats and shared vocabularies between organisations. Participation lets a vendor influence the shape of those interfaces, surface implementation constraints early, and document interoperability claims their procurement counterparties increasingly ask about. OBIS does not certify implementations, accredit vendors, or operate any process that ranks participating vendors against non-participating ones.

Authorities (supervisors, financial intelligence units, prosecutors, central-bank analytics units, law-enforcement bodies). OBIS specifications aim to make supervisory data more comparable across jurisdictions, reduce the bespoke-integration burden on reporting entities, and provide a shared technical baseline that prosecutors and courts can refer to when assessing the reliability of blockchain evidence. OBIS does not produce regulation, guidance, or interpretive commentary on existing instruments; it produces the technical artefacts that implementations of those instruments can build on. Authorities can engage as observers, as commenters on drafts in Public Review, or as co-editors and reviewers where their institution’s mandate permits.

Researchers (academic and applied). OBIS specifications provide shared schemas, vocabularies, and reproducibility primitives that let work compound across studies rather than restart from raw chain history each time. Participation is valuable both as a contributor (proposing or co-editing specifications that codify what the field already knows) and as a user (citing OBIS specifications in methods sections, allowing other groups to reproduce and extend results). Research outputs that depend on specific attribution data, taxonomies, or data layers are particularly well-served by being expressed in terms of an open specification.

Reporting entities (VASPs, exchanges, custodians, payment institutions handling virtual assets). OBIS specifications in the regulatory-reporting focus area aim to reduce the cost of maintaining bespoke integrations with each supervisor and counterparty. Reporting entities have direct visibility into where bespoke-integration cost actually falls, which makes their input on draft exchange formats especially valuable. Engagement does not require a regulatory commitment of any kind; it is technical input into the design of formats that the entity may or may not eventually adopt.

Co-editors and external reviewers#

The current OBIS drafts are edited by a single founding editor. This reflects the project’s early stage rather than its intended steady state. OBIS is actively seeking co-editors and named external reviewers for each draft, particularly from organisations and jurisdictions not yet represented in the contributor base.

If you have relevant expertise — practitioner experience in investigations, supervisory or prosecutorial work, research on blockchain data, or implementation experience with blockchain analytics tooling — and are interested in serving as a co-editor or named reviewer on one of the current drafts, please open an issue on the relevant repository or write to info@obistandards.org.