Skip to main content
Tracer is Lerian’s platform for real-time transaction validation and spending controls. It helps financial institutions enforce spending policies, detect unauthorized transactions, and maintain audit-ready compliance records. Tracer does this in real time, before a transaction executes. For every transaction, Tracer evaluates your business rules and spending limits, then returns an instant decision: allow, deny, or flag for review. In Midaz v4, Tracer is source-available under ELv2 in the Midaz repository and release. It remains a separate runtime and deployment from the Ledger service.

Tracer in a complete core banking


Tracer is one of the pieces of a Lerian core banking, its real-time control layer. A ledger records what happened. Tracer decides what’s allowed to happen first. In that flow, before your application records a transaction in Midaz, it calls Tracer to check the move against your rules and spending limits. Your application submits to the ledger only if the decision is ALLOW, so unauthorized or over-limit movements never reach the ledger. Tracer stays separate from the ledger: it never initiates a call to Midaz and never reads balances. It evaluates the context it receives, records validation history, and manages reservation state. By default your application orchestrates the two, submitting to the ledger only on ALLOW. Midaz can also call Tracer directly through an optional per-ledger reservation seam, which is off by default. In that seam the Ledger HTTP v2 transaction path holds limit capacity before it commits a transaction, and then confirms or releases the hold. Tracer’s public HTTP API remains /v1. The seam is not a public Tracer v2 API. Only the Ledger HTTP v2 transaction path invokes the seam. Ledger HTTP v1 never does. In both flows, calls go toward Tracer. Tracer does not call back into Midaz. For where this sits in the bigger picture, see Building a complete core banking.

Why use Tracer?


Financial institutions need to control how money moves: enforcing spending caps, blocking unauthorized transactions, and producing audit trails for regulators. Doing this manually or through batch processes creates delays, errors, and compliance gaps. Tracer solves this by evaluating every transaction in real time against your policies. It provides two capabilities:
  • Validation rules: Business rules that evaluate transaction context and return instant decisions, without requiring code deployments. You define rules using expressions, not code, making them accessible to analysts and compliance teams.
  • Dynamic spending limits: Configurable limits per transaction, per account, per portfolio, per segment, or per merchant, with real-time usage tracking and automatic period resets.

Solving control and compliance challenges

Tracer helps institutions evaluate spending policies, identify unauthorized transactions, and satisfy audit requirements.

Key capabilities


  • Real-time validation with response times under 80ms (p99)
  • Expression-based rule engine using for type-safe, analyst-friendly rules
  • Product-agnostic design supporting multiple transaction types:
    • Card transactions (debit, credit, prepaid)
    • Wire transfers (domestic, international, ACH)
    • Pix (instant, scheduled)
    • Cryptocurrency (bitcoin, ethereum, stablecoin)
  • Dynamic spending limits:
    • Per transaction, account, portfolio, segment, or merchant
    • Daily, weekly, monthly, custom, or per-transaction periods
  • Real-time limit usage tracking with automatic period resets
  • Complete audit trail with 7+ year retention for SOX/GLBA compliance
  • Configurable no-match default (DEFAULT_DECISION_WHEN_NO_MATCH): when no rule matches a transaction, Tracer returns the configured default (ALLOW for fail-open, DENY for fail-closed). Infrastructure failures surface as HTTP errors. The calling system decides the fallback behavior.

How it works


Tracer has four core contexts:
  1. Validation Context - Orchestrates validation requests, coordinates rule and limit evaluation, and records the audit trail.
  2. Rules Context - Manages rule definitions, compiles expressions, and evaluates rules against transaction context.
  3. Limits Context - Manages spending limit configurations, tracks usage counters, and enforces thresholds.
  4. Audit Context - Keeps the immutable event log and verifies its hash chain for SOX/GLBA compliance.
When your system submits a transaction for validation:
How Tracer processes a validation request across its Validation, Rules, and Limits contexts and returns an ALLOW, DENY, or REVIEW decision; the Audit Context is intentionally not shown

Figure 1. How Tracer works

Tracer evaluates all active rules, and if any DENY rule matches, it returns a DENY decision. Tracer checks limits against current usage and returns the decision with a complete audit record. Your system must act on this decision (e.g., blocking the transaction, showing an error to the user, or queuing for review).

Who does what

Tracer sits between several teams. Each team owns a different part of the loop: A typical request flows: authorization system → Tracer (evaluate rules + check limits → decision) → audit log → response back to authorization system. Risk and product teams set up rule and limit definitions beforehand. Compliance reads the audit log later. Tracer never reaches back into your stack. There are no webhooks or callbacks.
Monetary values (transaction amount, spending limit maxAmount, and usage counters) use decimal strings, for example "1500.00" or "50000.00".

When to use Tracer


Tracer fits naturally into any workflow where you need to control how money moves through your institution.
  • Spending governance: Evaluate transactions against internal or customer-level spending policies
  • Transaction validation: Evaluate custom business rules and return decisions before transaction execution
  • Regulatory compliance: Produce audit-ready logs and ensure traceability
  • Customer protection: Detect overspending and return decisions that your system can act on

Scope and design principles


Tracer is a transaction validation engine, not a complete fraud management system. It is a specialized component optimized for low-latency decisions (< 100ms) that validates pre-enriched payloads against configurable rules and limits.

What Tracer focuses on

  • Rule-based validation: Deterministic, expression-based logic using CEL
  • Spending limits: Real-time enforcement with automatic period reset
  • Audit trail: Immutable records for compliance (SOX/GLBA)
  • Low-latency decisions: Synchronous API responses under 80ms (p99)

What Tracer does not include

These boundaries keep Tracer fast and predictable: it returns instant transaction decisions with complete audit trails.

Integration


Your authorization system sends validation requests with complete transaction context, and Tracer responds with a decision, typically in under 35ms. With this Payload-Complete Pattern, all the context Tracer needs arrives in a single request. There are no external calls during validation, and latency stays predictable.
Tracer runs single-tenant by default and supports multi-tenant operation when deployed in SaaS or BYOC Multi-Tenant mode. In multi-tenant mode, tenant resolution and isolation work the same way as in the rest of the platform. See Multi-tenancy for the model and Access Manager for the auth flow.
Like all Lerian products, Tracer ships with native Access Manager integration. When enabled, Access Manager handles authentication and authorization for Tracer’s APIs. This is an optional feature available under the Enterprise model.

Next steps


Explore the Tracer API

Browse endpoints for validation rules, spending limits, and audit trails.

Getting started

Set up Tracer and configure your first authorization rule.