Data Methodology
From blockchain activity to a reviewable statement.
Understand the questions behind sources, attribution, interpretation, and coverage.
- Raw activityObserved on-chain
- Normalized record
- Sourced contextSourced reference
- Analytical interpretationAnalytical inference
- Reviewable outputLimitation recorded
Illustrative methodology flow — no live data
Principles
From a source to a statement.
Information should move through traceable stages before it becomes an analytical statement. A methodology explanation should make the origin and limits of information clear.
Preserve the source
Keep the origin point of every claim.
Separate fact from interpretation
Show what was observed apart from what was inferred.
Record uncertainty
State confidence and limitations alongside the result.
Keep conclusions reviewable
Let another reviewer follow the reasoning.
Not every data point is complete, current, or independently verified. This page describes how information is intended to be handled and where its boundaries lie; it does not, by itself, confirm an implemented analytical method for any specific output.
Source-to-statement workflow
Seven stages, from source to a reviewable statement.
- Data stages: what was received and recorded
- Interpretation stages: what was inferred from it
-
1
Collect the source
Data- Input
- Blockchain node or indexed data; public, partner, or customer-submitted records
- Transformation
- None; received as supplied
- Source reference
- Origin point recorded
- Timestamp
- Ingestion logged against block confirmation time
- Reviewer context
- Source category noted
- Known limitation
- Reflects on-chain activity only; completeness varies by blockchain
-
2
Record provenance
Data- Input
- The collected source
- Transformation
- Origin attached to each claim
- Source reference
- Provenance indicator
- Timestamp
- Time of collection
- Reviewer context
- Basis for the claim is visible
- Known limitation
- Each source category carries distinct confidence levels
-
3
Normalize the information
Data- Input
- Block headers, transaction inputs and outputs, contract interactions, event logs
- Transformation
- Structured into consistent records
- Source reference
- Link back to the raw record
- Timestamp
- Preserved from ingestion
- Reviewer context
- Can be compared with the raw record
- Known limitation
- Scope varies by blockchain; documented per network on request
-
4
Connect relevant references
Data- Input
- Normalized records and sourced references
- Transformation
- References related to addresses and entities
- Source reference
- Reference attached
- Timestamp
- Reference date
- Reviewer context
- Disputed or pending labels are flagged
- Known limitation
- Labels may be under dispute or pending reverification
-
5
Apply analytical methods
Interpretation- Input
- Records and references
- Transformation
- Heuristic analysis of transaction patterns
- Source reference
- Signals retained
- Timestamp
- Methodology version in effect
- Reviewer context
- Output is interpretation, not fact
- Known limitation
- A cluster is not a verified identity without corroboration
-
6
Record confidence and limitations
Interpretation- Input
- Analytical output
- Transformation
- Confidence context and limitations attached
- Source reference
- Basis for confidence
- Timestamp
- When assessed
- Reviewer context
- Reviewer can see remaining uncertainty
- Known limitation
- Risk scores are analytical output, not determinations
-
7
Produce a reviewable statement
Interpretation- Input
- Assessed output with its context
- Transformation
- Presented with source, confidence, and limits
- Source reference
- Traceable to source
- Timestamp
- Recorded with the output
- Reviewer context
- Another reviewer can reconstruct the reasoning
- Known limitation
- Interpret alongside additional due diligence
Illustrative workflow. Stage details describe the intended handling of information, not a specific output.
Sources and provenance
Where information comes from.
Blockchain data ingestion
Data is ingested from blockchain nodes and indexed data sources across supported networks. Raw transaction data includes block headers, transaction inputs and outputs, smart contract interactions, and event logs where applicable. The scope of ingestion varies by blockchain and is documented per network in technical specifications available upon request.
Off-chain data integration
Entity attribution incorporates public records, corporate registries, voluntary disclosures by service providers, and verified submissions from customers and partners. Each source category carries distinct confidence levels and verification standards. Provenance documentation indicates the origin point for each attribution claim.
Data freshness
Block processing latency varies by network congestion, node synchronization status, and data source reliability. Timestamped ingestion logs record when data entered the system relative to block confirmation times.
Source limitations
Blockchain data reflects on-chain activity only. Off-chain transactions, private transactions on supported privacy layers, and obfuscated flows through mixing services may not be fully visible. Data completeness varies by blockchain implementation and network upgrade history.
Source register
| Source category | Information type | Collection method | Timestamp | Provenance status | Known limitation |
|---|---|---|---|---|---|
| Direct blockchain observation | Blocks, transactions, contract interactions, event logs | Ingestion from nodes and indexed sources | Ingestion logged | Directly observed | On-chain activity only |
| Publicly available information | Public records, corporate registries, open-source intelligence | Public sources | To be confirmed | Source supplied | Quality varies by region and registry access |
| Customer-provided information | Verified customer submissions | Customer submission | To be confirmed | Source supplied | Distinct verification standards |
| Partner or third-party information | Voluntary disclosures, partner data sharing | Agreement or disclosure | To be confirmed | Source supplied | Distinct confidence levels |
| Analyst-created interpretation | Analyst research and assessment | Analyst work | To be confirmed | Analyst interpreted | Interpretation, not fact |
Illustrative register layout using only source types described on this page. Review status varies by source category.
Tracing one statement back to its source
- Original sourceDirectly observed
- Collection eventDirectly observed
- Normalized recordDirectly observed
- Supporting referenceSource supplied
- Analytical noteAnalyst interpreted
- Review historyUpdated
Other states a record can carry: Independently corroborated Unverified
Illustrative provenance trace, not a real record.
Attribution and interpretation
Three layers, kept apart.
- Observation
- Address
- Transaction
- Asset
- Network
- Amount
- Timestamp
- Attribution
- Sourced entity reference
- Cluster relationship
- Provenance indicator
- Confidence context
- Interpretation
- Analytical assessment
- Risk indicator
- Reviewer note
- Remaining uncertainty
Clustering methodology
Address clustering groups blockchain addresses based on heuristic analysis of transaction patterns, including common input ownership, change address detection, and temporal behavior analysis. Clustering confidence levels indicate the strength of the underlying heuristic signals. Clusters are not equivalent to verified entity identities without additional corroboration.
Entity labeling
Labels applied to clusters derive from multiple sources: verified customer submissions, open-source intelligence (OSINT), partner data sharing agreements, and analyst research. Each label carries a provenance indicator showing the basis for the attribution. Labels subject to dispute or pending reverification are flagged accordingly.
Risk scoring
Risk signals combine multiple inputs: direct attribution to known high-risk entities, indirect exposure through transaction proximity, behavioral pattern matching, and typology indicators. Risk scores represent analytical output subject to interpretation, not definitive determinations of illicit activity.
A cluster, label, or risk indicator does not by itself prove identity, ownership, intent, or wrongdoing.
Confidence and uncertainty
How certainty should be communicated.
Each statement should carry a plain-language state. No numerical confidence percentages or scoring formulas are used here.
- Confirmed by direct sourceStated by the originating source itself.
- Supported by multiple referencesMore than one reference points the same way.
- Probable analytical relationshipSignals favour a relationship; corroboration is limited.
- Possible relationshipSignals are consistent with a relationship but do not favour it.
- UnknownNot enough information to say.
- Conflicting informationReferences disagree and the disagreement is recorded.
What the information does not establish.
- Correlation versus causationCorrelation does not establish causation.
- Transaction proximityProximity to a high-risk entity does not prove involvement in illicit activity.
- Address clusteringA cluster is not a verified entity identity without additional corroboration.
- Entity attributionLabels may be disputed or pending reverification and carry a provenance indicator.
- Risk indicatorsRisk scores are analytical output, not definitive determinations. Interpret them alongside additional due diligence.
- Incomplete network visibilityData completeness varies by blockchain implementation and network upgrade history.
- Off-chain activityBlockchain data reflects on-chain activity only.
Updates and corrections
How information changes, and how that is recorded.
- 1New information received
- 2Source reviewed
- 3Record compared
- 4Correction approved
- 5Affected output updated
- 6Revision recorded
Data refresh cycles
Entity attributions and risk designations are subject to periodic review. Update frequencies vary by data category and source volatility. High-risk entity lists may update in near-real-time; structural attribution (exchange wallets, mining pools) updates on discovery of new addresses or infrastructure changes.
Correction procedures
Attribution errors reported by users or identified through internal review are queued for reverification. Corrections are applied upon confirmation through independent verification against source data. Historical data states are retained for audit purposes while current views reflect corrected information.
Versioning and auditability
Material changes to analytical methodologies are documented with effective dates. Historical queries can be reconstructed against methodology versions active at the time of the original analysis.
Methodology history
Material methodology changes should remain traceable to the period in which an analysis was produced. A change record shows an effective date, the reason for the change, the reviewer, and the previous and updated state.
| Methodology version | Effective date | Change summary | Affected analytical area | Review status | Supporting documentation |
|---|---|---|---|---|---|
| Version A (example) | Date recorded | Summary recorded | Area recorded | To be confirmed | Available on inquiry |
| Version B (example) | Date recorded | Summary recorded | Area recorded | To be confirmed | Available on inquiry |
| Version C (example) | Date recorded | Summary recorded | Area recorded | To be confirmed | Available on inquiry |
Illustrative history layout. It contains no real versions, dates, or changes.
Coverage
What may be available, and what needs confirming.
-
Blockchain coverage
What may be available
Data coverage is maintained for networks listed in the platform documentation. Coverage depth varies: some networks support full historical analysis; others provide limited historical depth or real-time monitoring only. Specific coverage parameters are available per blockchain upon inquiry.
What requires confirmation
- Specific network
- Historical depth
- Update cadence
- Data-source availability
-
Asset coverage
What may be available
Support for specific token standards (ERC-20, SPL, etc.) varies by underlying blockchain implementation. Native chain assets are generally supported; bridged assets, wrapped tokens, and synthetic assets may have limited visibility depending on bridge architecture and data availability.
What requires confirmation
- Asset or token standard
- Data-source availability
- Product or deployment context
-
Geographic and jurisdictional limitations
What may be available
Attribution data quality varies by region based on corporate registry accessibility, regulatory disclosure requirements, and data partner coverage. Sanctions list coverage reflects publicly available lists from designated issuing authorities; delays in list updates or jurisdictional variations in sanctions implementation may affect screening completeness.
What requires confirmation
- Geographic relevance
- Data-source availability
- Update cadence
-
Methodology evolution
What may be available
Analytical approaches are subject to refinement as blockchain ecosystems evolve. Methodology changes are evaluated for impact on historical analyses and communicated to affected customers when material.
What requires confirmation
- Update cadence
- Product or deployment context
Known blind spots
Not all blockchain activity can be seen.
These areas present inherent analytical limitations. Coverage of them is explicitly documented where supported.
Privacy-preserving protocols
Private transactions on supported privacy layers may not be fully visible.
Layer-2 networks
Networks with limited data availability present inherent analytical limitations.
Off-chain settlement
Blockchain data reflects on-chain activity only.
Obfuscation techniques
Mixers, coinjoins, and privacy coins may obscure flows.
Incomplete public records
Attribution data quality varies with registry accessibility, disclosure requirements, and partner coverage.
Bridged and wrapped assets
Bridged assets, wrapped tokens, and synthetic assets may have limited visibility.
Jurisdictional differences
Delays in list updates or differences in sanctions implementation may affect screening completeness.
Methodology review checklist
Questions for an informed evaluation.
Use these questions to review any analytical statement. They are guidance, not a claim that every answer is available for every output.
For detailed methodology documentation, coverage specifications by blockchain, or to discuss the analytical approach behind specific outputs, contact methodology@fintraceintelligence.com.
- Which source produced the information?
- When was it collected or updated?
- Is it observed, sourced, or inferred?
- What supporting reference exists?
- What confidence or limitation applies?
- Has contradictory information been considered?
- Can another reviewer reconstruct the reasoning?
- What coverage assumptions require confirmation?
Bring your methodology questions into focus.
Discuss the sources, coverage, attribution context, and limitations your team needs to evaluate.