Four-Eyes Deploy Controls in Finance — The Gap Between Theory and What Actually Works

A common one-line question from financial IT auditors: "Are deploys subject to four-eyes control?"

Saying yes doesn't end the conversation. The next question is how. That's where the patterns that work split from the patterns on paper.

This post is the four actually-working patterns I've seen across six banks.

Why paper four-eyes stops the pipeline

The simplest implementation — every production deploy requires explicit approval from two people. It doesn't work, for three reasons:

1. Nightly batch breaks at 02:00 and the second person is not awake.
2. Hot fix needs to go in within five minutes; the second person's response time is in minutes.
3. The bypass token / emergency override built to handle the above gets abused, weakening four-eyes itself.

Pattern 1 — time-tier four-eyes

Business hours (09–18) — standard four-eyes. Nights / weekends — one operator + post-hoc review.

Time tier        | Pre-approval | Post-hoc review
─────────────────┼──────────────┼───────────────────
09–18 weekdays   | 2 persons    | 0
Nights / weekend | 1 person     | by 09:00 next biz day

Skip the post-hoc review and night ops becomes plain 1-eye. Many implementations miss this.

Pattern 2 — four-eyes by change tier

Not every deploy receives the same control. Change risk tier sets the strength of four-eyes.

Tier | Change kind                       | Control
─────┼───────────────────────────────────┼──────────────────────────────
S    | Core payment / balance / auth     | 2 persons + security + CTO
A    | General business logic            | 2 persons
B    | UI / non-business backend         | 1 person + auto-validation
C    | Static assets / docs              | Auto-merge + post-hoc review

Automatic tier classification is load-bearing. If humans tag the tier, everything ends up at the lowest tier.

Pattern 3 — implicit four-eyes — PR review + deployer

The PR reviewer is the first eye, the person triggering the deploy is the second eye. As long as those two are different people, four-eyes is satisfied.

git log:
  PR author:    alice
  PR reviewer:  bob       ← first eye
  PR approver:  bob       
  Deploy:       charlie   ← second eye, must differ from alice and bob

This pattern satisfies both paper and operations most cleanly. Whether auditors accept it varies bank by bank. In Korean FSC audits we've seen — accepted twice, rejected once.

Pattern 4 — machine + human four-eyes

An automated validation system is the first eye, a human is the second. The automated system must hold explicit control authority with its own audit trail.

1. Automated: static analysis + security scan + regression tests → on pass, *machine approval stamp*
2. Human: PR review + explicit approval
3. Deploy: both stamps required

Precise, but infrastructure-heavy. If the automated validator breaks, the whole pipeline halts — meaning the validator itself must be highly available.

Six banks' actual choices

Bank | Pattern adopted          | Outcome
─────┼──────────────────────────┼─────────────────────────────────────
A    | Pattern 1 (time tier)    | Operates, post-hoc review backlog
B    | Pattern 2 (change tier)  | Satisfied, auto-tiering load-bearing
C    | Pattern 1 + 2            | Cleanest, most expensive
D    | Pattern 3 (implicit)     | Auditor rejected, switched to 2
E    | Pattern 4 (machine+human)| Infra burden, fell back to 2
F    | Pattern 1 + 3            | Operates, passed audit once

Most-frequently-passing: Pattern 2 (change tier). Most-frequently-rejected: Pattern 3 (implicit) — auditors find it insufficiently explicit.

The core — explicitness

What the four working patterns share is explicitness. What four-eyes is, when it applies, and how must be named in code, policy, and tooling. Reliance on good intent or practice doesn't pass audit.

Can "we run four-eyes" alone pass an audit?

In financial and public-sector deploy-control audits, answering "we apply four-eyes" is not enough to pass. If the how isn't explicitly one of the four patterns above (time tier / change tier / implicit / machine+human), expect "recommendation for improvement" or "non-compliance" at the next audit. If you own IT operations in this sector, the one thing to check now is where your four-eyes is named — in code, policy, or tooling.