Add Fraud Triage environment: transaction risk-decisioning RL task

[atharvsatpute]

Summary

Adds a Fraud Triage environment: a sequential transaction risk-decisioning
RL task where an agent must approve/flag/escalate/block synthetic
transactions. Fills a gap in the existing finance environments (finrl_env
covers stock trading, finqa_env covers document QA) — neither covers
transaction-level risk decisioning.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation
• New environment
• Refactoring

Alignment Checklist

Before submitting, verify:

• I have read .claude/docs/PRINCIPLES.md and this PR aligns with our principles
• I have checked .claude/docs/INVARIANTS.md and no invariants are violated
• I have run /pre-submit-pr (or bash .claude/hooks/lint.sh and tests) and addressed all issues

RFC Status

• Not required (bug fix, docs, minor refactoring)
• RFC exists: #___
• RFC needed (will create before merge)

Test Plan

Ran the existing test suite locally:

All 4 tests pass:

• test_reset_returns_valid_observation
• test_approve_and_block_actions_return_reward
• test_episode_terminates_after_episode_length_steps
• test_state_tracks_confusion_matrix_counts

Also manually verified end-to-end with a heuristic policy (amount z-score

• new-device/new-merchant thresholds) achieving 100% fraud recall over a
  200-transaction episode, confirming the reward signal and episode
  termination behave as intended.

Environment follows existing Gym-style conventions (see connect4_env) —
Pydantic wire types, WebSocket-based client, no MCP tool exposure, rewards
computed entirely server-side inside step().

Claude Code Review

N/A

---

Note

Low Risk
Self-contained new environment under envs/ with no changes to core auth or shared runtime; risk is limited to new code paths and CI integration-test flakiness from spawning a server on port 8000.

Overview
Introduces fraud_triage_env, a new OpenEnv environment for sequential payment fraud triage: each step presents one synthetic transaction with risk-style features, and the agent chooses APPROVE, FLAG, ESCALATE, or BLOCK.

The server implements reset / step / state via FraudTriageEnvironment, scoring decisions against hidden labels with an asymmetric reward (heavy penalty on missed fraud, lighter on false positives, extra cost on ESCALATE) and tracking TP/FP/FN/TN plus cumulative reward. Transactions come from a lightweight TransactionGenerator with overlapping fraud vs. legit distributions and configurable episode_length / fraud_rate.

Wiring matches other envs: Pydantic models, FraudTriageEnv WebSocket client on EnvClient, FastAPI app from create_app, openenv.yaml, Docker image, README, and integration tests that boot the server and exercise reset, step rewards, episode termination, and state metrics.

^{Reviewed by Cursor Bugbot for commit f17e2a8. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

Want higher recall? High effort reviews run extra passes and find more bugs. A team admin can switch effort levels in the Cursor dashboard.

^{Reviewed by Cursor Bugbot for commit 2ccb2a3. Configure here.}

[cursor]

Steps after episode done

Medium Severity

step() does not stop processing once the episode has ended. After the final transaction, _current_txn stays set and further step() calls score the same transaction again, incrementing step_count, confusion-matrix counters, and cumulative_reward beyond episode_length.

 

^{Reviewed by Cursor Bugbot for commit 2ccb2a3. Configure here.}

[atharvsatpute]

Hi everyone, I've addressed the main items and the PR is ready. Could a maintainer please trigger the automated tests? (Note: I already checked the Bugbot output and everything looks good on that end). Thanks for your time!

[burtenshaw]

Thanks! Could you also deploy this space on hugging face for review of the runtime?