Fraud detection and credit agents that actually run at transaction volume.

Your fraud detection agent catches synthetic identity fraud better than your rules engine. It works in staging. It demos well. But when transaction volume spikes 10x on a Friday afternoon, it falls over. Hatch fixes that.

The problem.

When the Experian API returns a 429 during a batch credit pull, your agent's Kafka consumer has already committed the offset. The retry logic reprocesses the entire partition — not just the failed record. The loan applicant gets two credit inquiries. Your credit bureau contract charges per pull. At 500 applications a day, this is not a corner case; it's a weekly incident that your on-call rotation handles manually because nobody built idempotent retry into the original agent.

Fraud detection agents fail in a different way. Your model runs a gRPC call to the feature store, scores the transaction, and writes the decision to Postgres. If the Postgres write times out after the score is computed, the agent has no safe default: retry risks a duplicate block, skip risks letting fraud through. Without step-level state persistence, every agent implements this logic from scratch — usually wrong, usually discovered in a production incident at 2am.

Your compliance team needs a queryable audit trail before they'll sign off on any agent that touches a credit decision. Not stdout logs aggregated in CloudWatch — structured records with the input payload, the model version, the rules applied, the confidence score, and the final decision, all keyed to the application ID and timestamped to the millisecond. Building that on top of a vanilla Kubernetes deployment takes weeks and is never quite complete enough to satisfy an examiner.

What Hatch handles.

Hatch persists agent state to a write-ahead log after each step. If the Experian API call at step 2 succeeds but the Postgres write at step 3 fails, the agent resumes from step 3 on restart with the bureau data already in context — the credit pull is not retried, the applicant gets one inquiry, and the partition offset is only committed after the full workflow completes.

Kafka consumer groups are managed by Hatch's autoscaler, which reads lag on the transaction topic and scales agent replicas from 2 to 200 based on queue depth — not CPU. During Friday afternoon spikes, new pods are warm within 90 seconds. When lag clears, they scale back down. No HPA tuning, no manual intervention.

Every agent decision is written to an append-only audit log: input payload hash, step-by-step execution trace, model version and inference ID, rule evaluations with pass/fail, and final output. The log is queryable by application ID, agent version, decision outcome, or time range. Your compliance team gets read-only access to a structured API, not a request to your data eng team.

Human approval gates are modeled as durable pause points. When a fraud score exceeds a threshold, the agent writes a review record, pauses, and sends a Slack notification to your fraud ops queue. The workflow resumes only when an analyst calls the approval endpoint — with their user ID and timestamp logged. Timeouts escalate automatically. The agent does not poll; it waits on a durable signal.

Agents that run on Hatch.

Transaction monitor

Consumes from a Kafka topic of raw transactions, calls a gRPC feature store for velocity and identity signals, runs the fraud model, writes the decision to Postgres with full provenance, and publishes a block or clear event back to the transaction topic. Ambiguous scores route to a human review queue with the full feature vector attached.

10,000+ transactions/hour with sub-200ms decision latency

Credit decisioning agent

Pulls loan applications from an SQS queue, calls Experian and TransUnion sequentially with idempotent retry, runs underwriting rules against the bureau response, and writes a structured approval or denial with full reasoning to the origination system. Bureau calls are deduplicated by application ID so partial failures never trigger double pulls.

500+ applications/day across multiple lending products

Compliance monitor

Subscribes to a CDC stream from the transaction database, evaluates each settled transaction against OFAC, BSA, and internal policy rules, writes structured violation records with severity and rule reference to a compliance sink, and generates daily PDF reports for your BSA officer with no manual data wrangling.

Continuous monitoring across all transaction types

The 2-week PoC.

Take your existing fraud detection or credit decisioning agent — the one that's built but stuck in staging. Deploy it on Hatch. In two weeks, it processes real transaction volume with idempotent Kafka consumption, step-level state recovery, and a compliance-ready audit log queryable by your team.

10,000 transactions/hour processed with zero duplicate decisions from retry

Sub-200ms p99 decision latency measured under sustained load with queue autoscaling active

Full structured audit log queryable by application ID, agent version, and decision outcome

Automatic step-level recovery from bureau API failures — no partition reprocessing, no double credit pulls

Why now.

The CFPB's proposed rule on automated decision systems requires adverse action notices that reference the specific factors an AI model used — not a generic 'credit score too low.' Your agent already computes those factors. If they're not in an auditable, structured log tied to each decision, you're building the logging infrastructure under regulatory pressure, not before it. The OCC's model risk guidance (SR 11-7) applies to credit models regardless of whether a human or an agent makes the call.

Have an agent stuck in staging?

Tell us what it does and where it's stuck. We'll scope a 2-week PoC and show you what production looks like.

book a call →