3 Apr 2026

The IBM-ARM collaboration deserves more attention from UK financial services technology leaders than it's getting. Everyone is focused on the AI models sitting on top of infrastructure, but the infrastructure decisions being made right now will constrain what's actually possible for the next decade.

The specific thing here is native ARM execution on IBM enterprise systems. That sounds dry until you realise what it means for organisations running mission-critical workloads, which in consumer credit means loan origination, decisioning engines, and real-time affordability checks. These are not workloads you migrate casually or experiment with on commodity cloud.

ARM's power efficiency story is genuinely compelling at scale. A large broker or lender running continuous credit bureau calls, fraud checks, and open banking data processing is burning significant compute. If ARM-native workloads can deliver the same throughput at lower energy cost without requiring a full re-architecture, that changes the capital conversation in IT budget cycles.

The bit I'd push back on is the framing around "infrastructure choice without rebuilding existing systems." That promise has been made before, and the integration tax always shows up somewhere. Usually in middleware, monitoring, or the skills gap when your team knows one architecture deeply and now needs to support two.

For UK consumer finance specifically, there's a regulatory dimension worth watching. The FCA and PRA are increasingly interested in operational resilience and third-party concentration risk. A dual-architecture platform could either help here, by reducing single-vendor dependency, or complicate things by adding surface area to your resilience testing obligations.

The question I'd be asking is not whether ARM on IBM enterprise hardware is technically viable. It probably is. The question is whether your engineering organisation has the depth to make that choice deliberately rather than by accident when a vendor makes it attractive enough.