A trading platform's team wants trunk-based development, but a bad deploy has financial consequences. Are the two compatible?

They are compatible, and the reasoning matters

Long-lived branches do not reduce risk; they concentrate it. A branch merged after three weeks contains many changes, tested together, released together — so when something breaks, the cause is one of dozens of changes and the rollback removes all of them.

Trunk-based development with small changes means each change is individually attributable and individually reversible, which is a stronger safety property, not a weaker one.

What must accompany it in a high-consequence system

• Progressive delivery. Trunk-based development is about integration frequency, not about exposing every change to every user immediately. A change merged to trunk is deployed behind a flag and enabled gradually.
• Automated verification that is genuinely trusted, including the fitness functions that assert the characteristics that matter — latency budget on the order path, dependency direction, absence of forbidden calls.
• A fast, exercised rollback, so the response to a problem is measured in minutes.
• Automated halt conditions on the rollout, triggered by error rate or latency rather than by a human noticing.
• A change freeze around known-critical windows, which for a brokerage means market hours — this is a scheduling constraint rather than a branching one, and it coexists with trunk-based development.

The specific consideration for financial correctness

Some changes cannot be progressively rolled out because they alter shared state semantics or a calculation whose consistency across users matters. Those need a different treatment — a coordinated change, a migration sequence, or a maintenance window — and identifying which changes fall into that category is a design activity rather than a deployment one.

Treating every change as progressively deliverable is as wrong as treating none as such, and the classification should be explicit.

The evidence

Teams with high deployment frequency and small change size have lower change failure rates and faster recovery, not higher. The intuition that less frequent releases are safer is one of the most robustly contradicted beliefs in delivery practice — and the mechanism is exactly the attribution and reversibility described above.