System requirements
Infrastructure
| Component | Minimum | Recommended | Purpose |
|---|---|---|---|
| CPU | 2 cores | 4+ cores | Matching and scoring logic is CPU-intensive |
| Memory | 2 GB | 4+ GB | In-memory processing of transaction batches |
| Storage | 10 GB | 50+ GB | Persistent storage for transactions and audit logs |
Dependencies
Matcher depends on the following services:- PostgreSQL 15+: Primary data store for reconciliation contexts, transactions, matches, and audit logs.
- Redis 7+: Used for caching, duplicate detection, distributed locking, and idempotency control.
- RabbitMQ 3.12+: Message broker for asynchronous processing across bounded contexts.
Runtime
Matcher lets you the following runtimes and tooling:- Go 1.24+ (only required when building from source)
- Docker 24+ and Docker Compose 2.20+ for containerized deployments
- Kubernetes 1.28+ for production-grade deployments using Helm
Optional: Midaz integration
Matcher can optionally integrate with Midaz Ledger to query ledger transactions directly. This integration is entirely optional—Matcher works as a stand-alone product reconciling any data sources.
When to use Midaz integration
Use the Midaz integration if:- You’re using Midaz as your ledger system
- You want to reconcile Midaz transactions against external sources
- You want automatic transaction synchronization from Midaz
When Midaz is not needed
Matcher works independently when:- Reconciling between external systems (banks, ERPs, payment processors)
- Using a different ledger system
- Importing ledger data via CSV/JSON/XML files
Connection requirements
To enable Midaz integration, ensure that:- A Midaz instance is running and reachable from Matcher’s network
- API access is configured with permissions to query transactions
- Shared authentication is enabled via lib-auth (same identity provider)
Configuration
Configure the Midaz connection through environment variables:See the Midaz Integration guide for complete setup instructions.
Authentication
Matcher uses lib-auth for authentication and authorization, consistent with the rest of the Lerian ecosystem.
Authentication flow
- The client obtains a JWT from the identity provider
- The token is sent in the
Authorization: Bearer <token>header - Matcher validates the token via lib-auth
- Tenant identity and permissions are extracted from token claims
Required permissions
Access to Matcher features is controlled through fine-grained permissions:| Permission | Description |
|---|---|
config:context:create | Create reconciliation contexts |
config:context:read | View context configuration |
config:rule:create | Create and update match rules |
ingestion:import:create | Upload transaction files |
matching:job:run | Execute matching jobs |
exception:item:list | View exceptions |
exception:item:resolve | Resolve exceptions |
governance:report:read | Access reports and audit views |
Single-tenant mode
If authentication is disabled or no tenant identifier is present in the JWT, Matcher runs in single-tenant mode using a default tenant.Supported file formats
Matcher accepts transaction data in the following formats. Each format has specific structural requirements for successful ingestion.
CSV (comma-separated values)
Commonly used for bank statements and exports. Requirements:- Header row is required
- UTF-8 encoding
- Comma delimiter (configurable)
- Quoted fields for values containing delimiters
JSON (javascript object notation)
Recommended for API-based integrations. Requirements:- Valid JSON array of transaction objects
- UTF-8 encoding
- Consistent field names across records
XML (extensible markup language)
Common in enterprise and banking integrations. Requirements:- Single root element
- UTF-8 encoding
- Consistent element structure
File size limits
| Limit | Default | Configurable via |
|---|---|---|
| Maximum file size | 100 MB | HTTP_BODY_LIMIT_BYTES |
| Maximum transactions per file | 100,000 | Context-level configuration |
Network requirements
Inbound access
Matcher exposes a REST API that must be reachable by clients:| Port | Protocol | Purpose |
|---|---|---|
| 8080 | HTTP | API server (default) |
| 8443 | HTTPS | API server with TLS |
Outbound access
Matcher must be able to reach the following services:| Service | Purpose | Required |
|---|---|---|
| PostgreSQL | Data persistence | Yes |
| Redis | Caching and coordination | Yes |
| RabbitMQ | Messaging | Yes |
| Auth service | Token validation | If authentication is enabled |
| Midaz API | Ledger queries | Optional (only if using Midaz) |
| JIRA / ServiceNow | Exception routing | Optional |
| Custom webhooks | Event notifications | Optional |
TLS configuration
For production environments, configure TLS:Environment checklist
Before proceeding with installation, confirm that:
- Infrastructure is ready: PostgreSQL, Redis, and RabbitMQ are running and accessible
- Authentication is configured: Auth service is available, or auth is explicitly disabled
- Network access is validated: Required inbound and outbound connectivity is in place
- Credentials are available: Database credentials and API tokens are configured
- Sample data is prepared: Transaction files are ready for testing (see Quick Start)

