What Are Confidence Scores?
Confidence scores are objects with two fields:value: An integer from 0 to 100 representing certaintyreasons: An array of string tags explaining the score
Score Ranges
- 0: No confidence (should not be used)
- 50: Low confidence (uncertain match)
- 75: Moderate confidence (likely correct)
- 90: High confidence (very likely correct)
- 100: Maximum confidence (definitive match)
Where Scores Appear
Confidence scores appear at multiple levels in the response:Overall Transaction Confidence
Category Confidence
Per-Entity Confidence
Each entity in theentities array has its own confidence:
Confidence Reason Tags
Reason tags explain what contributed to or detracted from the confidence score. They are divided into several categories.Global Reasons
These can appear on any entity type (merchant, location, or intermediary):| Tag | Meaning |
|---|---|
results_consensus | Multiple independent sources/results point to the same entity |
ambiguous_entity | Multiple plausible candidates; evidence does not uniquely identify one |
results_contradict | Top results disagree on key identity fields, indicating uncertainty |
insufficient_evidence | Not enough reliable evidence to support a strong match |
Category Reasons
Applied to the category confidence score (deterministic, code-only):| Tag | Meaning |
|---|---|
merchant_category_match | The identified merchant has a known/linked category mapping |
fallback_classification | Category came from fallback logic rather than strong merchant evidence |
p2p_transfer_detected | Transaction detected as P2P transfer by deterministic rules |
Merchant Reasons
Applied to merchant entity confidence (global + merchant-specific):| Tag | Meaning |
|---|---|
broad_merchant_name | Extracted merchant string is too broad to uniquely identify a business |
generic_descriptor | ”Merchant name” is primarily a descriptor rather than a proper noun |
name_closely_matched | Chosen merchant name matches the raw transaction tokens strongly |
name_inferred | Output name differs from extracted name because AI inferred the likely correct name |
brand_disambiguated | AI resolved a brand ambiguity based on evidence |
category_consistent_with_context | Merchant type implied by evidence matches transaction context/category |
Location Reasons
Applied to location entity confidence (global + location-specific):| Tag | Meaning |
|---|---|
country_match | Location country aligns with expected country hints |
wrong_country | Location country doesn’t aligns with expected country hints |
city_match | City token is present in raw or strong context and matches chosen location city |
store_id_match | Store number/branch ID appears in raw and matches a specific store |
single_result_match | Only one strong relevant place result exists and it matches clearly |
identifier_match | Specific identifier matches (street, phone, postal code, store code) |
address_closely_matched | Address text in results aligns closely with chosen location fields |
multiple_plausible_locations | Several plausible places exist and evidence doesn’t uniquely select one |
chain_location_disambiguated | For chains, AI selected a specific branch based on evidence |
Intermediary Reasons
Applied to intermediary entity confidence (global + intermediary-specific):| Tag | Meaning |
|---|---|
name_closely_matched | Intermediary name matches raw tokens strongly |
processor_role_disambiguated | AI resolved whether entity acts as processor/gateway vs actual merchant |
platform_vs_merchant_disambiguated | AI resolved platform vs underlying merchant |
known_processor_match | Deterministic match to internal processor dictionary (prefix/pattern) |
Score Interpretation
- 90-100: Very High
- 70-89: High
- 50-69: Moderate
- 0-49: Low
Interpretation: Highly reliable for automated decisions When you see
this: - Transaction string closely matches known patterns - Multiple data
points confirm the identification - Entity is well-known with clear
signatures Common reasons:
results_consensus, name_closely_matched,
known_processor_match Recommended action: Use directly in your
application without reviewConfidence by Entity Type
Different entity types typically have different confidence distributions:| Entity | Typical Range | Notes |
|---|---|---|
| Merchant | 70-99 | Well-known merchants score higher |
| Location | 50-95 | Store-level matching is harder |
| Category | 75-99 | Based on merchant + context |
| Intermediary | 90-99 | Distinct patterns, high accuracy |
| Person | 85-99 | Extracted directly from transaction string |
Using Confidence in Your Application
Threshold-Based Logic
Using Reason Tags
Displaying Confidence to Users
Filtering by Confidence
Best Practices
Set appropriate thresholds for your use case
Set appropriate thresholds for your use case
Different applications have different tolerance for errors. A personal
finance app might accept lower confidence than a compliance system.
Consider the cost of errors
Consider the cost of errors
If incorrect categorization has serious consequences, require higher
confidence thresholds or manual review.
Use reason tags for smarter decisions
Use reason tags for smarter decisions
Track confidence distributions
Track confidence distributions
Monitor the confidence scores you’re seeing. Consistently low scores for
certain transaction types might indicate a need for different handling.
Report issues for low-confidence matches
Report issues for low-confidence matches
Use the Issue Report API to flag incorrect enrichments. This helps improve
accuracy over time.
Next Steps
Error Handling
Handle errors and partial results gracefully
Report Issues
Report enrichment issues to improve accuracy