Authoring velocity and MCC rules with the Citi-Source editor

The Rules tab in the Issuer workspace is where card program rules — velocity caps, MCC restrictions, geographic limits, decline-reason text — are authored, reviewed, versioned, and deployed. The editor uses the Citi-Source rule language under the hood so rules can move between issuers using the same backend.

The change-request lifecycle:

Rules don't get applied directly. Every change is a versioned RuleChangeRequest that goes through review:

1. **Author** — pick the program. Click "Propose change." The editor opens with the current rules pre-filled.
2. **Edit** — change velocity caps, add an MCC to the allow list, edit the decline-reason text, tweak the geographic restriction. Each line shows a diff against the current version.
3. **Save as draft** — saves the changes as a RuleChangeRequest. Status starts as "draft."
4. **Submit for review** — moves status to "pending review." Notifies a separate authorizer (per the two-person rule — see below).
5. **Approver reviews** — different user opens the RCR, reviews the diff, attaches a justification comment, clicks Approve or Reject.
6. **Deploy** — approved RCRs can be deployed to production. Status moves to "approved" → "deployed."

The two-person rule:

For compliance, the user who proposes a change cannot be the same user who approves it. If you propose, you can save and edit your draft as much as you want, but you can't click Approve. A second user with rule-edit permission has to approve.

This is enforced server-side — see [feedback_rule_change_two_person] for the audit trail.

Velocity rules — common patterns:

- **Per-transaction cap**: `max_single_transaction: 5000` (dollars).
- **Per-day cap**: `max_per_day: 25000`.
- **Per-month cap**: `max_per_month: 100000`.
- **Velocity by MCC**: `max_per_day_in_mcc('5812-restaurant'): 250` so dining can't blow the budget.

MCC rules — the typical pattern:

- **Allow list**: start with deny-all, add specific MCCs your program needs (e.g. office supplies 5111, software 7372, fuel 5541).
- **Deny list**: start with allow-most, add specific high-risk MCCs (e.g. 7995 gambling, 5993 cigar stores).
- Federal GSA SmartPay GTC programs have specific MCC deny lists mandated by Federal Travel Regulation — those ship pre-configured.

Geographic rules:

Country-level: `country in ['US', 'CA', 'MX']`. State-level via BIN routing. Real-time geolocation enforcement isn't supported — the card network's auth message carries the merchant's country code which is what we evaluate.

What "deploy" actually does:

Pressing Deploy on an approved RuleChangeRequest:
1. Writes a new RuleSet Version to the program.
2. Stops applying the old version effective immediately.
3. Writes a SHA-256-stamped audit record (proves what was deployed when).
4. Notifies the program's adopters of the change (if their notification policy is set to "all rule changes" — otherwise only material rule changes per the OpenCardsDataStandard).

Reverting a deploy:

You can't un-deploy. Authorizations against the old version don't roll back. But you can deploy a new version that reverses the change. The audit log shows both: "Deployed v12 (allow 5811)" then "Deployed v13 (deny 5811 — reverting v12)."