> ## Documentation Index > Fetch the complete documentation index at: https://docs.lerian.studio/llms.txt > Use this file to discover all available pages before exploring further. # What is Tracer? > Validate transactions in real time with Tracer: enforce spending limits, detect unauthorized activity, and decide allow/deny under 100ms. export const GCEL = ({children}) => {children} ; **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](/en/products/tracer/integration-guide#midaz-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](/en/products/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 CEL (Common Expression Language) 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 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: | Actor | What they do | Touches | | -------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- | | **Risk / fraud analyst** | Writes and tunes rules ("deny Pix over R\$ 50k from new accounts") | `POST /v1/rules`, `/v1/rules/{id}/activate`, audit trail review | | **Product / risk manager** | Configures spending limits per segment, portfolio, account | `POST /v1/limits`, lifecycle endpoints, usage monitoring | | **Integration engineer** | Builds the call from the authorization system into Tracer | `POST /v1/validations`, retry / timeout / fallback handling | | **Authorization system** | Sends every transaction for validation, acts on ALLOW / DENY / REVIEW | Hits `POST /v1/validations` on the critical path | | **Midaz ledger** (optional seam) | When the per-ledger reservation seam is enabled, holds limit capacity before committing and settles the hold afterwards | `POST /v1/reservations`, then the confirm / release transitions | | **Tracer** | Evaluates rules and limits, records the result, returns the decision | Runs internally — never calls back | | **Compliance / audit** | Queries the trail, verifies hash chain integrity, runs SOX/GLBA reports | `GET /v1/validations`, `/v1/audit-events`, `/v1/audit-events/{id}/verify` | | **SRE / platform** | Monitors latency, capacity, readiness | Watches `/readyz`, OTel metrics, error rates | 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 | Capability | Reason | Alternative | | ---------------------------- | ------------------------------------------------------------ | ----------------------------------------------------------------------- | | **Machine learning scoring** | ML inference adds latency incompatible with sub-100ms target | Integrate external ML services upstream and pass scores via metadata | | **Data enrichment** | External calls during validation break latency guarantees | Enrich payloads in your integration before calling Tracer | | **Manual review workflows** | Case management is outside core validation scope | Build review queues in your system and use `REVIEW` decision as trigger | | **User interface** | API-first design enables flexible integration | Build custom UIs or use third-party tools | | **Payment execution** | Tracer returns validation decisions; it does not move funds | Execute or block payments in the upstream system based on the decision | 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](/en/platform/multi-tenancy) for the model and [Access Manager](/en/platform/access-manager) for the auth flow. Like all Lerian products, Tracer ships with native [Access Manager](/en/platform/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 *** Browse endpoints for validation rules, spending limits, and audit trails. Set up Tracer and configure your first authorization rule.