MintMap
Docs
Financial observability platform

See every dollar move.
Catch every break.

MintMap is Datadog for money movement. Trace one payment from capture to settlement across every system — and know the instant something goes missing, duplicated, delayed, or mismatched.

✓ Ingest from anywhere ✓ One canonical event model ✓ Every break is explainable & replayable
trace order_1001 · Acme Marketplace India
1 break
payment.captured · razorpay
10:30:00 · matched
+₹1,000.00
fee.assessed · razorpay
10:30:01 · matched
−₹23.60
settlement.created · razorpay
Jul 15 · matched
₹976.40
bank.credit · hdfc
Jul 16 · amount mismatch
₹964.40 expected ₹976.40
ledger.posted · netsuite
waiting — blocked by break
—
⚠
₹12.00 short at HDFC. Processor settled ₹976.40 but the bank credited ₹964.40. Incident opened, seller payout on hold.
Ingests from APIWebhooksKafka SQSSFTPS3 CSV / XLSXBank filesManual entry
100%
of money movement traced, capture to settlement
6+
systems reconciled per journey — processor, bank, wallet, ledger, ERP
1
canonical FinancialEvent — every source, rail & currency
0
mutable financial truth — immutable events, replayable state
The flow

From raw payload to reconciled truth

Every input path — however it arrives — becomes the same canonical event before reconciliation ever runs.

01

Ingest

Send events any way that works: API, webhook, Kafka, SQS, SFTP, S3, or a CSV drop.

→
02

Normalize

Map raw fields into one immutable FinancialEvent. Dedupe, validate, quarantine bad data.

→
03

Trace

Stitch events into one end-to-end money journey — spans ordered from capture to posting.

→
04

Reconcile

Match expected vs. actual. Open an incident the moment a break crosses your threshold.

What you get

Observability for money, not just servers

◎

End-to-end money traces

Follow one trace_id across processor, bank, wallet, ledger and ERP. Every step is a span with its own status.

⚖

Rule-based reconciliation

Match on trace, amount, account or time window — with tolerances and settlement-delay windows you control.

⚠

Break detection

Missing, duplicated, delayed, partial or amount-mismatched — each break is classified, explained and routed.

⌘

Plug-and-play ingestion

Eight ingestion modes, one event shape. Point us at a queue, a bucket, or an endpoint and start sending.

↺

Replay & audit

Raw payloads stored for every event. Fix a mapping, replay quarantined data, and keep a full audit trail.

◈

Entity-aware

Reconcile across subsidiaries, sellers, merchants and accounts — a first-class entity registry, not free text.

Plug-and-play

Send us your events however works for you

The rule that makes it simple: every input path produces the exact same canonical event before reconciliation starts.

APIPOST /v1/events
Webhooksigned URL per source
Kafkatenant topics
SQSscoped queue consumer
SFTPscheduled folder poll
S3 / objectbucket & prefix import
File uploadCSV · XLSX · JSON · bank
Manual entryadjustments & corrections

Trace your first rupee in an afternoon

Define your entities once, connect a source, and watch MintMap normalize, trace and reconcile every break.

How it works

Every input becomes one canonical event

MintMap is not a payment processor, ledger or settlement engine. It's the observability layer that watches money move across all of them — strict internally, simple for you.

1

Ingest from any source

A connector authenticates the source, stores the raw payload untouched for audit, and hands it to the pipeline. It doesn't matter whether it arrived by API, webhook, Kafka, SQS, SFTP, S3, file upload, or manual entry.

auth & authzraw payload storesignature verify
2

Map & normalize

Clients who can't send our format define a mapping — field renames, type & amount conversion, timestamp parsing, entity lookup from external IDs. The result is a single immutable FinancialEvent. Anything that can't be mapped is quarantined with a clear error, never dropped.

field mappingamount / 100entity lookupquarantine
3

Dedupe & store

Idempotency keys stop the same event landing twice. Validated events are appended to an immutable event store; a stream backbone publishes raw, normalized, reconciled and incident events downstream to analytics, search and graph stores.

idempotencyimmutable appendevent stream
4

Trace the journey

Events sharing a trace_id are projected into ordered spans — one end-to-end money journey. The overall trace status follows the worst span: one break, and the whole trace flags.

trace_id → spansworst-status wins
5

Reconcile & alert

Rules group candidate events, compute expected vs. actual, and mark each matched, partial, delayed, duplicate or mismatched. Cross a threshold and an incident opens, routed to Slack, email, PagerDuty or a webhook — with the raw evidence attached.

tolerancessettlement windowsincidents
One contract

The canonical FinancialEvent

Every payment, refund, fee, settlement, bank movement and ledger posting — Razorpay in ₹, Stripe in $, a wallet in €, all in one place — becomes the same immutable shape. Read models are derived; the event is the source of truth.

payment.capturedfee.assessed settlement.paidbank.credit ledger.postedrefund.completed
financial-event.v1.json 
// immutable · tenant-scoped · replayable
{
  "event_id": "8e7b93a9-…-b4016fb2ef0b",
  "tenant_id": "acme-commerce-group",
  "entity_id": "acme_marketplace_us",
  "source_id": "stripe_webhook_primary",
  "trace_id": "order_4820",
  "event_type": "payment.captured",
  "amount": "149.00",
  "currency": "USD",
  "event_status": "succeeded",
  "reconciliation_status": "unmatched",
  "schema_version": "financial-event.v1"
}
Reconciliation scopes

Match at whatever level the money breaks

The same rules engine runs from a single transaction all the way up to an entire tenant.

trace-level
One end-to-end journey — did every step of ORD-1001 line up?
pair-level
Stripe payouts ($) vs. bank credits; Razorpay settlements (₹) vs. HDFC.
entity-level
One legal entity or seller — seller payable ledger vs. actual payouts.
account-level
One wallet, ledger or bank account — wallet balance vs. bank escrow.
batch-level
One settlement file or bank statement reconciled row by row.
tenant-level
Every entity for a client, in one sweep across all sources.
rule · stripe-payout 
For each payment.captured from stripe:
  expected bank.credit =
      amount − fees − taxes
  match by trace_id or payout_id
  allow settlement delay up to 2 business days
  allow amount tolerance up to $0.01
  else → open incident, hold payout
Explainable by design

Every result is replayable

Bad data never blocks good data. When a payload can't be mapped or validated it's quarantined with a clear reason. Fix the mapping, replay the payload, and the break resolves — with the full history of what changed preserved for audit.

acceptednormalizedquarantined replayedreconciledincident_created

See it run on your data

Bring a settlement file and a bank statement — we'll normalize both and surface the breaks live.

Why MintMap

Finance teams stop chasing spreadsheets

Reconciliation today means exports, VLOOKUPs and a Slack thread at month-end. MintMap makes money movement observable in real time — so breaks find you, not the other way around.

◎ Built for the money layer

APM tools watch requests and latency. MintMap watches value — amounts, currencies, fees, settlements and the accounts they land in — with reconciliation as a first-class primitive.

  • Immutable events, never mutable balances
  • Amounts, tolerances and currencies understood natively

◈ One model, every source

No more per-integration reconciliation scripts. Eight ingestion modes collapse into one canonical event, so a new processor or bank is a mapping, not a rebuild.

  • Add a source without touching your rules
  • Entity registry spans subsidiaries & sellers

⚠ Breaks that explain themselves

Every incident carries the trace, the expected vs. actual amounts, and the raw payloads behind it. No archaeology — the root cause ships with the alert.

  • Classified: missing, duplicate, delayed, mismatch
  • Routed to Slack, email, PagerDuty or webhook

↺ Nothing is lost

Raw payloads are retained for every event. Fix a mapping and replay months of history; keep a complete audit trail of every source, rule and manual change.

  • Replay quarantined or corrected data anytime
  • Audit log for mappings, rules & adjustments
The difference

Spreadsheets end where MintMap begins

CapabilityManual / spreadsheetsMintMap
When you find a breakAt month-end closeThe moment it happens
Data across systemsRe-exported & re-joined by handOne canonical event model
Trace one transactionGrep across five exportsOne trace, capture → posting
Root cause of a mismatchManual investigationShipped with the incident
Adding a new processorA new script & a new sheetA mapping — rules unchanged
Audit & replayWhatever the file still saysImmutable, fully replayable
Security & isolation

Tenant-scoped down to the last event

Every runtime object belongs to a tenant. Isolation isn't a setting — it's the data model.

⚿

Scoped credentials

API keys and webhooks are scoped to a tenant and source; queue consumers use scoped credentials only.

✓

Signed webhooks

Inbound webhooks support signature verification, so only genuine source payloads enter the pipeline.

⌾

Encrypted at rest

Raw payloads are encrypted at rest and retained for audit, replay and evidence on every incident.

⧉

Idempotent ingestion

Idempotency keys prevent duplicate events — re-sending a file returns duplicates, not double counts.

◐

Role-based access

Control who can edit mappings, entities and rules; sensitive changes are gated by role.

▤

Full audit log

Source changes, rule changes, manual uploads and adjustments are all recorded and attributable.

Make your money movement observable

Book a 30-minute walkthrough. Bring your messiest reconciliation and we'll trace it.