Skip to main content
Transaction enrichment is the core capability of Triqai. It takes raw, unstructured transaction strings from bank statements and transforms them into clean, structured data that’s easy to understand and use.

​
The Problem

Bank transaction data is notoriously messy. A simple coffee purchase might appear as: 
POS 4392 STARBUCKS STORE #1234 NEW YORK NY 10001
This string contains useful information: merchant name, store number, location, but it’s buried in noise and inconsistent formatting. Every bank formats transactions differently, making it impossible to reliably extract meaning without specialized processing.

​
The Solution

Triqai analyzes transaction strings using a combination of:
  • Pattern matching against known merchant signatures
  • Natural language processing to extract entities
  • Extensive merchant databases (150M+ companies)
  • Location intelligence (10M+ places globally)
  • Machine learning models for classification and confidence scoring
The result is structured data you can immediately use in your application.

​
Enrichment Pipeline

When you submit a transaction for enrichment, it goes through several stages:
1

Parsing

The raw transaction string is tokenized and analyzed for structure.
2

Entity Detection

Potential merchants, locations, and other entities are identified.
3

Matching

Detected entities are matched against our databases of known merchants, locations, and processors.
4

Classification

The transaction is categorized and additional metadata (channel, subscription status) is determined.
5

Scoring

Confidence scores are calculated for each enrichment field.

​
Enrichment Modules

Each enrichment request activates multiple specialized modules:

​
Merchant Enrichment

Identifies the business or entity behind the transaction and provides:
  • Normalized merchant name
  • Logo and brand color
  • Website and domain
  • Business description
  • Alternative names (aliases)

​
Location Enrichment

Extracts geographic information including:
  • Formatted address
  • City, state, country
  • Postal code
  • GPS coordinates (latitude/longitude)
  • Timezone

​
Category Classification

Assigns hierarchical spending categories:
  • Primary category (e.g., “Shopping”)
  • Secondary category (e.g., “Online Shopping”)
  • Tertiary category (e.g., “Marketplace”)
  • Industry codes (MCC, SIC, NAICS)

​
Payment Processor Detection

Identifies intermediary payment services:
  • Processor name (Stripe, PayPal, Square, etc.)
  • Underlying merchant (when detectable)
  • Processor branding

​
P2P Platform Detection

Recognizes peer-to-peer transfer platforms:
  • Platform identification (Venmo, Zelle, Cash App)
  • Recipient information
  • Transfer memo (when available)

​
Additional Signals

  • Channel: How the transaction occurred (online, in-store, mobile, ATM)
  • Subscription: Whether this is a recurring payment and its type

​
Request Format

A basic enrichment request requires three fields: 
{
  "title": "AMAZON MKTPLACE PMTS AMZN.COM/BILL WA",
  "country": "US",
  "type": "expense"
}
FieldTypeRequiredDescription
titlestringYesRaw transaction description from bank statement
countrystringYesISO 3166-1 alpha-2 country code (e.g., “US”, “NL”, “GB”)
typestringYesTransaction direction: expense or income

​
Enrichment Status

Each enrichment module returns a status indicating the result:
StatusDescription
foundEntity was successfully identified
no_matchNo matching entity could be found
not_applicableModule doesn’t apply to this transaction type

​
Partial Results

Sometimes not all enrichment modules succeed. For example, a transaction might have a recognized merchant but no identifiable location. In these cases:
  • The response includes partial: true
  • Successful enrichments are returned normally
  • Failed enrichments have status: "no_match"
  • No credits are deducted for partial results
{
  "success": true,
  "partial": true,
  "data": {
    "enrichments": {
      "merchant": {
        "status": "found",
        "confidence": 95,
        "data": { /* merchant data */ }
      },
      "location": {
        "status": "no_match",
        "confidence": null,
        "data": null
      }
    }
  },
  "meta": {
    "errors": ["location_timeout"]
  }
}

​
Best Practices

The country code helps Triqai narrow down merchant and location matching. An incorrect country code may lead to less accurate results.
Don’t pre-process or truncate transaction titles. The full string often contains valuable signals like store numbers and location hints.
The type field (expense vs income) helps classify refunds, transfers, and income sources correctly.
Check confidence scores before displaying data to users. Low-confidence results may need manual review.

​
Next Steps

Categories

Learn about the category taxonomy

Entities

Understand merchant, location, and processor data

Confidence Scores

How to interpret and use confidence scores

API Reference

See the full API documentation