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 — all 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. Response times stay under 100ms, so customers experience no delays. Tracer is available to licensed customers; its repository is maintained internally.

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, and only submits to the ledger if the decision is ALLOW — so unauthorized or over-limit movements never reach the ledger in the first place. Tracer stays separate from the ledger: it never calls Midaz and never reads balances — it only evaluates the context sent to it. 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 — off by default — where the ledger holds limit capacity before it commits a transaction and then confirms or releases the hold. Either way, traffic flows into Tracer, never out of it. 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 foundational 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. Whether you need to detect transactions that exceed spending caps, evaluate custom business rules, or maintain a complete audit trail for SOX/GLBA compliance, Tracer provides the speed, flexibility, and governance required for modern financial operations.

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 is built around 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 a transaction is submitted 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

All active rules are evaluated, and if any DENY rule matches, Tracer returns a DENY decision. Limits are checked against current usage, and the decision is returned with a complete audit record. Your system is responsible for acting 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. Rule and limit definitions are set up beforehand by risk/product; 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) are expressed as 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. This focused scope enables Tracer to deliver predictable performance while integrating seamlessly with broader fraud prevention ecosystems.

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, predictable, and focused on its core value: instant transaction decisions with complete audit trails.

Integration


Integrating with Tracer is straightforward. Your authorization system sends validation requests with complete transaction context, and Tracer responds with a decision—typically in under 35ms. This Payload-Complete Pattern keeps things simple: all the context Tracer needs arrives in a single request, so 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.