Architecture Review

Wrote docs/architecture/tasks/pay-gw-review-001/arch-review-task/architecture-review-report.md. One confirmed nonconformity, one criterion met within tested scope, three evidence gaps. The disposition below is a recommendation for the EAB, not an approval.

Architecture Review Report: payment-gateway v2.4.0-rc1 [ARR-PAY-001]

Summary

Review of payment-gateway v2.4.0-rc1 against PAY-ARCH-2026-v2 for the EAB production-release decision. Two criteria were examined.

FD-1 is a confirmed nonconformity: OAuth tokens are held unencrypted at rest in redis-pay and copied into daily RDB snapshots. The latency criterion is met in staging (FD-2). Three gaps (G-1 to G-3) limit what this review can say. Recommended disposition:

conditional acceptance, conditions C-1 to C-3. The EAB decides.

Review Subject and Mandate [RS-1]

Criteria

CR-1, POL-SEC-04 §3.2. Question: are access and refresh tokens encrypted at rest in every store that holds them? Oracle: each such store (primary memory, replicas, snapshots, backups) shows an at-rest encryption control.

CR-2, NFR-PAY-07. Question: is p99 authorization latency ≤ 250 ms at 400 TPS? Oracle: a load test on the exact subject revision.

No other criterion was applied. Severity is not assigned: no severity scale was supplied.

Evidence and Coverage

Covered: CR-1 for Redis primaries, replicas and RDB snapshots; CR-2 in staging. Not covered: other stores that may hold tokens, key management, production latency.

Findings

FD-1: confirmed nonconformity (CR-1)

• Location: spec §5.3, token cache in redis-pay; RDB snapshots in s3://pay-backups.
• Condition: tokens are cached in Redis with no at-rest encryption stated, TLS disabled, and copied to S3 by daily snapshots.
• Impact: anyone who can read replica memory, snapshot files or the backup bucket can read live tokens (TTL 900 s in the cache; retention of snapshots not supplied).
• Owner response: disputed. "Redis is network-isolated."
• Status: confirmed. Network isolation limits who can reach the cluster; POL-SEC-04 §3.2 requires encryption at rest, a different control. Whether isolation can stand in for encryption is an exception decision for the policy owner, not a reviewer call.
• Confidence: high for Redis (explicit in EV-1); medium for S3, because bucket encryption was not supplied (G-2).

FD-2: observation, criterion met within tested scope (CR-2)
LT-118 shows p99 212 ms at 400 TPS on rc1, below the 250 ms limit. This covers one 30-minute staging run; it says nothing about production traffic.

Gaps

• G-1: no inventory of other components that hold tokens (logs, queues, analytics exports).
• G-2: encryption setting of s3://pay-backups not supplied.
• G-3: owner of any key-management control not named.

Recommended Disposition for the EAB [DP-1]

Conditional acceptance, if the EAB agrees:

C-1 Evidence that tokens are encrypted at rest in redis-pay, either by the store or by the application before caching, verified on rc1 or a later revision.

• C-2 Evidence that s3://pay-backups encrypts snapshots at rest.
• C-3 A token-store inventory signed by the subject owner, closing G-1.

Alternative: a time-bound exception to POL-SEC-04 §3.2 granted by its policy owner, with scope, compensating controls and expiry.

Invalidation: any change to token storage, or a new subject revision, reopens CR-1.

Handoffs

Explicit Unknowns

Other token stores (G-1). Backup bucket encryption (G-2). Key-management owner (G-3). Production latency. Snapshot retention period.

Traceability

Verification

No validator was supplied, so no command was run. Reviewer self-checks, which support but do not replace the EAB decision:

• every finding traces to a criterion and evidence (FD-1: CR-1, EV-1, EV-3; FD-2: CR-2, EV-2);
• only the two supplied criteria were applied;
• the reviewer granted no approval.

Next steps

1. Send G-1 and G-2 requests to the payments team lead.
2. Put DP-1 on the EAB agenda with this report.
3. If the team pursues isolation instead of encryption, route the exception request to the POL-SEC-04 owner.