Composite Scenario: How a Tier-1 US Card Issuer Modernized with Bare-Metal Kubernetes and AI Inference

Composite Scenario: How a Tier-1 US Card Issuer Modernized with Bare-Metal Kubernetes and AI Inference

Executive Summary

COMPOSITE SCENARIO — This case study is a composite scenario based on publicly-documented engineering patterns from leading US card issuers and banks. It does not represent an actual THNKBIG engagement. Specific figures are illustrative of the archetype and aligned with industry benchmarks.

**Disclosure.** This engagement profile reflects the engineering patterns THNKBIG sees across Tier-1 US card issuers: bare-metal Kubernetes, regulated-data workloads on dedicated infrastructure, and shared AI inference platforms for fraud and risk models. It is not a single named client.

A top-5 US card issuer was running a hybrid estate — cloud-managed Kubernetes for digital channels, three-year-old bare-metal clusters for settlement, and a sprawling VM footprint for fraud and risk analytics. Container adoption had stalled at the application tier. The platform team could not keep pace with demand from the fraud models team, and the AI inference workloads that the data science org wanted to ship next quarter had no credible home.

THNKBIG was engaged to design and deliver two parallel programs: a bare-metal Kubernetes migration for the regulated workload tier, and a new AI inference platform for the fraud, risk, and customer-experience model portfolios. The work ran over nine months in three phases, and concluded with the bank's platform team fully owning both platforms post-handoff.

The result: a 38% reduction in infrastructure cost relative to the cloud-baseline projection, AI inference P99 latency falling from 800ms to 90ms, and a 100% first-attempt pass rate on the subsequent SOC 2 Type II and PCI-DSS audits.

38%
Infrastructure cost reduction (bare metal vs. cloud baseline)
800ms → 90ms
AI inference P99 latency (fraud models)
100%
SOC 2 Type II + PCI-DSS audit pass rate (first attempt)

Solution Implemented

THNKBIG designed a two-track program with a shared platform foundation.

Track 1 — Bare-metal Kubernetes for regulated workloads. The bank's regulated tier — settlement, cardholder data, and adjacent services within PCI-DSS scope — moved onto dedicated bare-metal Kubernetes clusters running a hardened distro (RKE2 in this composite), with the control plane and etcd on FIPS-validated hosts. Bare metal was not chosen for cost alone: the bank needed data-residency guarantees that its cloud footprint could not provide, and it needed predictable performance for the transaction-processing path. The migration followed a strangler pattern, with namespaces carved by workload class.

PCI-DSS-scope boundaries were enforced across four layers: Calico GlobalNetworkPolicies that segmented the cardholder data environment (CDE) from the rest of the cluster fleet; dedicated node pools with restricted Pod Security Standards plus taints and tolerations so non-CDE workloads could not schedule on CDE nodes; a dedicated secrets namespace and sealed-secrets workflow scoped to the CDE; and an admission and audit pipeline (OPA Gatekeeper plus kube-apiserver audit log forwarding to immutable storage) that produced the evidence trail the SOC 2 and PCI-DSS auditors ultimately relied on. Argo CD itself ran on a dedicated management cluster separated from the workload cluster, hardening the supply chain to the regulated tier.

Kubernetes consulting for financial services

Track 2 — AI inference platform on shared GPU pools. A second cluster family hosted the AI inference tier: H100 and L40S pools carved into logical GPU partitions, with vLLM as the primary inference engine and NVIDIA Triton as the alt for models that needed custom pre/post-processing. A model-serving API abstracted the inference backend from the consuming applications, and a cost-per-token dashboard (built on top of Kubecost's GPU reporting) gave the platform team and the fraud models team a shared view of spend. The same inference cluster served fraud, risk, and customer-experience models, with namespace-level isolation per use case.

Cloud migration and optimization

AI infrastructure consulting

Foundational layer — GitOps, observability, and policy. Both tracks ran on a single GitOps control plane: Argo CD for application delivery, Argo Rollouts for progressive delivery on the inference tier, and a sealed-secrets workflow for credential handling. Observability was Prometheus + Grafana for the K8s-native path, with a managed APM provider (Datadog in this composite scenario) carrying the application and AI inference latency signal. OPA Gatekeeper enforced namespace standards and pod security standards across both cluster families.

DevOps and GitOps implementation

Zero Trust security for Kubernetes

Outcomes Expected

Cost. Infrastructure cost reduction of 38% relative to the cloud-baseline projection, measured at the 12-month mark post-handoff. The largest contributors were the elimination of managed-Kubernetes control-plane premiums on the regulated tier, reduced egress spend on settlement traffic that stayed on bare metal, and GPU utilization improvements (averaged steady-state utilization on the pooled inference platform ran ~70%, up from ~30% on the per-team ad-hoc GPU VMs).

Performance. AI inference P99 latency for the production fraud model dropped from 800ms to 90ms. The dominant factor was the move from cold-starting inference on ad-hoc GPU VMs to warm GPU pools with vLLM's continuous batching — but the bare-metal network path also helped, removing one network hop versus the cloud-managed route.

Compliance. 100% first-attempt pass rate on the SOC 2 Type II and PCI-DSS audits run in the 90 days post-handoff. The bank's compliance team reported that the GitOps-driven change-control trail and the codified network policy were the highest-leverage audit artifacts.

Velocity. Deployment cadence for the regulated tier moved from monthly at engagement start to weekly by the end of Phase 3, as the bank's change-advisory board certified the Argo Rollouts + GitOps audit trail. Progressive delivery paired with the GitOps foundation removed the manual-change-window bottleneck that had constrained the team.

Team. Fourteen engineers earned CKA or CKAD certifications during the engagement. The bank's platform team exited the program with full operational ownership of both platforms and a documented runbook for ongoing operations.

Challenge

The card issuer was hitting three problems at once.

1. Cloud-managed Kubernetes was the wrong shape for regulated workloads. The bank's hybrid posture was inherited from an earlier cloud-first push: EKS for the digital channel apps, three regional AKS clusters for analytics, and a footprint of bare-metal RKE clusters that nobody wanted to touch. The cloud-managed tier was paying full price for control planes and managed-node premium while carrying workload that regulators expected to live on dedicated infrastructure. Per-VM egress and managed-service premiums added 30–35% on top of what an equivalent bare-metal footprint would cost.

2. AI inference had no platform home. The fraud models team was running inference on ad-hoc GPU VMs in AWS. P99 latency on the production fraud model — a gradient-boosted ensemble that the team had re-trained four times in the previous eighteen months — was 800ms at the API edge, and the team was burning senior engineering time on capacity planning. The data science org had a backlog of model candidates waiting on GPU capacity that the platform team could not provision.

3. Platform team was a hiring bottleneck. The platform engineering org was twelve people supporting 400+ developers. Every new model deployment, every compliance-driven config change, every cluster upgrade required platform team time. The bank could not hire fast enough to keep up — a pain signal that mirrors the broader Tier-1 FinServ market, where K8s-skilled engineers are scarce and the offer-to-hire cycle runs 4–6 months.

A migration was overdue. So was an AI inference platform. The two needed to land together, because putting the inference platform on top of the same cloud-managed tier would just compound the cost problem.

COMPOSITE SCENARIOThis case study is a composite scenario based on publicly-documented engineering patterns from leading US card issuers and banks. It does not represent an actual THNKBIG engagement. Specific figures are illustrative of the archetype and aligned with industry benchmarks.

**Disclosure.** This engagement profile reflects the engineering patterns THNKBIG sees across Tier-1 US card issuers: bare-metal Kubernetes, regulated-data workloads on dedicated infrastructure, and shared AI inference platforms for fraud and risk models. It is not a single named client.

A top-5 US card issuer was running a hybrid estate — cloud-managed Kubernetes for digital channels, three-year-old bare-metal clusters for settlement, and a sprawling VM footprint for fraud and risk analytics. Container adoption had stalled at the application tier. The platform team could not keep pace with demand from the fraud models team, and the AI inference workloads that the data science org wanted to ship next quarter had no credible home.

THNKBIG was engaged to design and deliver two parallel programs: a bare-metal Kubernetes migration for the regulated workload tier, and a new AI inference platform for the fraud, risk, and customer-experience model portfolios. The work ran over nine months in three phases, and concluded with the bank's platform team fully owning both platforms post-handoff.

The result: a 38% reduction in infrastructure cost relative to the cloud-baseline projection, AI inference P99 latency falling from 800ms to 90ms, and a 100% first-attempt pass rate on the subsequent SOC 2 Type II and PCI-DSS audits.

The card issuer was hitting three problems at once.

1. Cloud-managed Kubernetes was the wrong shape for regulated workloads. The bank's hybrid posture was inherited from an earlier cloud-first push: EKS for the digital channel apps, three regional AKS clusters for analytics, and a footprint of bare-metal RKE clusters that nobody wanted to touch. The cloud-managed tier was paying full price for control planes and managed-node premium while carrying workload that regulators expected to live on dedicated infrastructure. Per-VM egress and managed-service premiums added 30–35% on top of what an equivalent bare-metal footprint would cost.

2. AI inference had no platform home. The fraud models team was running inference on ad-hoc GPU VMs in AWS. P99 latency on the production fraud model — a gradient-boosted ensemble that the team had re-trained four times in the previous eighteen months — was 800ms at the API edge, and the team was burning senior engineering time on capacity planning. The data science org had a backlog of model candidates waiting on GPU capacity that the platform team could not provision.

3. Platform team was a hiring bottleneck. The platform engineering org was twelve people supporting 400+ developers. Every new model deployment, every compliance-driven config change, every cluster upgrade required platform team time. The bank could not hire fast enough to keep up — a pain signal that mirrors the broader Tier-1 FinServ market, where K8s-skilled engineers are scarce and the offer-to-hire cycle runs 4–6 months.

A migration was overdue. So was an AI inference platform. The two needed to land together, because putting the inference platform on top of the same cloud-managed tier would just compound the cost problem.

THNKBIG designed a two-track program with a shared platform foundation.

Track 1 — Bare-metal Kubernetes for regulated workloads. The bank's regulated tier — settlement, cardholder data, and adjacent services within PCI-DSS scope — moved onto dedicated bare-metal Kubernetes clusters running a hardened distro (RKE2 in this composite), with the control plane and etcd on FIPS-validated hosts. Bare metal was not chosen for cost alone: the bank needed data-residency guarantees that its cloud footprint could not provide, and it needed predictable performance for the transaction-processing path. The migration followed a strangler pattern, with namespaces carved by workload class.

PCI-DSS-scope boundaries were enforced across four layers: Calico GlobalNetworkPolicies that segmented the cardholder data environment (CDE) from the rest of the cluster fleet; dedicated node pools with restricted Pod Security Standards plus taints and tolerations so non-CDE workloads could not schedule on CDE nodes; a dedicated secrets namespace and sealed-secrets workflow scoped to the CDE; and an admission and audit pipeline (OPA Gatekeeper plus kube-apiserver audit log forwarding to immutable storage) that produced the evidence trail the SOC 2 and PCI-DSS auditors ultimately relied on. Argo CD itself ran on a dedicated management cluster separated from the workload cluster, hardening the supply chain to the regulated tier.

Kubernetes consulting for financial services

Track 2 — AI inference platform on shared GPU pools. A second cluster family hosted the AI inference tier: H100 and L40S pools carved into logical GPU partitions, with vLLM as the primary inference engine and NVIDIA Triton as the alt for models that needed custom pre/post-processing. A model-serving API abstracted the inference backend from the consuming applications, and a cost-per-token dashboard (built on top of Kubecost's GPU reporting) gave the platform team and the fraud models team a shared view of spend. The same inference cluster served fraud, risk, and customer-experience models, with namespace-level isolation per use case.

Cloud migration and optimization

AI infrastructure consulting

Foundational layer — GitOps, observability, and policy. Both tracks ran on a single GitOps control plane: Argo CD for application delivery, Argo Rollouts for progressive delivery on the inference tier, and a sealed-secrets workflow for credential handling. Observability was Prometheus + Grafana for the K8s-native path, with a managed APM provider (Datadog in this composite scenario) carrying the application and AI inference latency signal. OPA Gatekeeper enforced namespace standards and pod security standards across both cluster families.

DevOps and GitOps implementation

Zero Trust security for Kubernetes

The program ran nine months across three phases.

Phase 1 — Foundation (months 1–3). Bare-metal cluster build (RKE2, three control-plane nodes per region, dedicated etcd), network architecture (PCI-DSS scope boundaries, egress controls, service mesh evaluation), GitOps bootstrap with Argo CD, and the first workload cutover from the legacy VM tier. Kubecost deployed in observe-only mode to establish the cost baseline. First cohort of three engineers began CKA certification.

Phase 2 — Inference platform MVP (months 4–6). GPU pool provisioning and node setup, vLLM-based serving stack, model-serving API, end-to-end observability including the P99 latency SLO dashboards. The first fraud model migrated off ad-hoc GPU VMs and onto the new inference platform. Cost-per-token reporting went live. Second cohort of five engineers began CKAD.

Phase 3 — Hardening and scale-out (months 7–9). Multi-region disaster recovery (active-active for the digital channel tier, warm-standby for the AI inference tier), SOC 2 Type II and PCI-DSS audit preparation, full GitOps rollout across all application teams, and the third cohort of six engineers certified. The bank's platform team assumed full operational ownership with THNKBIG on call for the first 60 days post-handoff.

US card issuers operate under a regulatory load that most cloud-native case studies ignore. PCI-DSS scopes the cardholder data environment and the systems that touch it. SOC 2 Type II is the baseline expectation for any vendor handling customer data, and a Tier-1 issuer's internal platform is held to the same standard. GLBA governs the safeguarding of customer information, and the New York Department of Financial Services Part 500 regulation layers additional cybersecurity controls on institutions regulated in New York — relevant for any top-5 issuer regardless of headquarters.

PCI-DSS and SOC 2 compliance on Kubernetes

For a Tier-1 issuer, these frameworks are not optional. The choice between cloud-managed and self-managed Kubernetes is partly a regulatory question, not just a cost question. Data residency, dedicated infrastructure for in-scope workloads, and the ability to demonstrate auditable change control across the cluster fleet are baseline requirements — not optimization targets. The bare-metal path in this composite exists because the cloud-managed path could not credibly meet all three.

The secondary pressure on Tier-1 issuers in 2026 is AI workload gravity. Fraud models, credit decisioning, customer-experience personalization, and conversational agents are all moving from batch to real-time, and each is hungry for GPU capacity. A platform team that can ship a new inference endpoint in days, not quarters, becomes a competitive asset rather than a bottleneck.

THNKBIG's financial services practice is built around three commitments to the platform teams we work with.

1. The platform survives the engagement. Every FinServ engagement includes a structured knowledge-transfer plan — typically three cohorts of platform engineers rotating through CKA and CKAD certification, paired shadow rotations on the live clusters during the hardening phase. The engagement ends when the bank's team can run the platform without us. In this composite, fourteen engineers earned certifications during the nine-month program.

2. Compliance is a design input, not a checklist. PCI-DSS scope boundaries are enforced through network policy and dedicated node pools from day one. SOC 2 controls map to cluster configuration as code. The audit that closes the engagement establishes the monitoring cadence the bank will run annually, so the platform has to be audit-ready in steady state — not just at audit time.

3. The AI inference platform is built for the data science org, not the platform team. Cost-per-token dashboards, model-promotion workflows, and the model-serving API are first-class deliverables. If the data science org cannot self-serve model deployments, the platform team has not finished its job.

Kubernetes consulting for financial services

Cost. Infrastructure cost reduction of 38% relative to the cloud-baseline projection, measured at the 12-month mark post-handoff. The largest contributors were the elimination of managed-Kubernetes control-plane premiums on the regulated tier, reduced egress spend on settlement traffic that stayed on bare metal, and GPU utilization improvements (averaged steady-state utilization on the pooled inference platform ran ~70%, up from ~30% on the per-team ad-hoc GPU VMs).

Performance. AI inference P99 latency for the production fraud model dropped from 800ms to 90ms. The dominant factor was the move from cold-starting inference on ad-hoc GPU VMs to warm GPU pools with vLLM's continuous batching — but the bare-metal network path also helped, removing one network hop versus the cloud-managed route.

Compliance. 100% first-attempt pass rate on the SOC 2 Type II and PCI-DSS audits run in the 90 days post-handoff. The bank's compliance team reported that the GitOps-driven change-control trail and the codified network policy were the highest-leverage audit artifacts.

Velocity. Deployment cadence for the regulated tier moved from monthly at engagement start to weekly by the end of Phase 3, as the bank's change-advisory board certified the Argo Rollouts + GitOps audit trail. Progressive delivery paired with the GitOps foundation removed the manual-change-window bottleneck that had constrained the team.

Team. Fourteen engineers earned CKA or CKAD certifications during the engagement. The bank's platform team exited the program with full operational ownership of both platforms and a documented runbook for ongoing operations.

THNKBIG is a Kubernetes consulting and platform engineering firm that has spent the last several years building the practice around regulated workloads. The financial services team works exclusively with banks, card networks, insurance carriers, and FinTechs at the Tier-1 and Tier-2 scale. Engineers on the FinServ practice have run PCI-DSS-scope clusters, managed SOX-relevant change control, and shipped AI inference platforms under audit pressure.

The difference between THNKBIG and a Big-4 consultancy on this kind of work is technical depth. THNKBIG engineers write Terraform and Helm, not slide decks. The deliverable in a FinServ engagement is a working platform that the client's team owns — not a strategy document that the client has to staff to execute.

Our Fortune 500 FinServ bank case study

Bay Area FinTech compliance automation case study

How long does a Kubernetes migration take for a bank? A typical Tier-1 bank migration runs 9–18 months end to end, depending on workload count and the depth of PCI-DSS-scope boundaries. The strangler-pattern approach used in this composite runs faster than a big-bang cutover, but it requires sustained platform team capacity across the engagement.

What compliance frameworks apply to Kubernetes in financial services? The baseline frameworks for a US card issuer are PCI-DSS (for cardholder data), SOC 2 Type II (for customer data more broadly), GLBA (for safeguarding customer information), and — for institutions regulated in New York — NYDFS Part 500. Additional frameworks may apply depending on the issuer's footprint (FFIEC for federally-regulated banks, state-level data privacy laws, etc.).

How much does Kubernetes cost optimization save a mid-size bank? Cost optimization on Kubernetes in financial services typically runs 25–45%, depending on the starting point. The biggest levers are bare-metal migration for steady-state workloads, GPU pooling for AI inference, and right-sizing via Kubecost or equivalent cost visibility tooling.

References

Industry Context

Sector-Specific Challenges

Financial institutions operate under intense regulatory scrutiny while facing pressure to modernize legacy systems and deliver competitive digital experiences. These organizations must maintain 99.99% uptime for transaction processing, protect against sophisticated cyber threats, and ensure complete auditability of all system changes and data access.

Technical Considerations

Technical requirements for financial services infrastructure include real-time transaction processing with sub-millisecond latency, comprehensive data encryption at rest and in transit, multi-region disaster recovery with automatic failover, and immutable audit trails for regulatory examinations. Systems must support complex compliance reporting and risk management analytics.

Regulatory Environment

Financial services infrastructure typically must comply with SOC 2 Type II, PCI DSS for payment processing, GLBA for consumer data protection, and often additional requirements like FINRA rules for broker-dealers or OCC guidelines for banks.

Our Approach

Our Kubernetes consulting methodology combines deep platform expertise with proven enterprise practices. We begin with a comprehensive assessment of your current state, including infrastructure inventory, application architecture review, and team capability evaluation. This foundation enables us to develop a tailored roadmap that addresses your specific business objectives while establishing sustainable operational practices.

Engagement Phases

  1. 1
    Discovery and Assessment: Infrastructure audit, application portfolio analysis, and skills gap identification
  2. 2
    Architecture Design: Platform architecture, networking topology, security controls, and GitOps workflow design
  3. 3
    Platform Build: Cluster provisioning, CI/CD pipeline setup, monitoring stack deployment, and policy implementation
  4. 4
    Migration Execution: Workload containerization, staged migration, performance validation, and cutover planning
  5. 5
    Operations Enablement: Runbook development, team training, on-call procedures, and knowledge transfer

Key Deliverables

  • Production-ready Kubernetes platform with hardened security configurations
  • GitOps-based deployment pipelines with automated testing gates
  • Comprehensive monitoring and alerting with custom dashboards
  • Disaster recovery procedures with tested failover capabilities
  • Team enablement program with hands-on training and documentation

Frequently Asked Questions

How long does a typical Kubernetes implementation take?

The timeline for Kubernetes implementation varies based on complexity and scope. A basic production cluster can be deployed in 4-6 weeks, while enterprise-scale implementations with multiple clusters, advanced networking, and comprehensive security typically require 3-6 months. We recommend a phased approach that delivers value incrementally while building toward the complete target architecture.

What Kubernetes distributions do you work with?

We have deep expertise across all major Kubernetes distributions including Amazon EKS, Azure AKS, Google GKE, Red Hat OpenShift, and Rancher. We also work with vanilla Kubernetes and specialized distributions for edge computing and air-gapped environments. Our recommendations are based on your specific requirements rather than vendor preferences.

How do you handle multi-cloud environments?

We design architectures that provide portability through Kubernetes and infrastructure-as-code while leveraging cloud-specific services where they provide clear advantages. Consistent tooling across clouds simplifies operations, while workload placement decisions optimize for cost, performance, and compliance requirements.

What cost optimization strategies do you implement?

We implement FinOps practices including resource right-sizing, reserved capacity planning, spot instance utilization, and automated scaling. Comprehensive tagging enables cost allocation and showback. Continuous optimization identifies waste and opportunities for savings.

How do you handle GPU resource management for ML workloads?

We implement Kubernetes-native GPU scheduling with fractional GPU support, enabling efficient sharing of expensive GPU resources across multiple workloads. Our configurations include automatic scaling based on queue depth, priority-based scheduling for different workload types, and monitoring for GPU utilization optimization.

Related Solutions

This case study demonstrates our expertise in the following service areas. Learn more about how we can help your organization achieve similar results.

Cloud Complexity is a Problem — Until You Have the Right Team

From compliance automation to Kubernetes optimization, we help enterprises transform infrastructure into a competitive advantage.

Talk to a Cloud Expert