Skip to content

SYSTEM Cited by 1 source

Santander Catalyst

What it is

Catalyst is Santander's in-house internal developer platform (IDP), co-built with AWS Professional Services via the Platform Strategy Program (PSP). It abstracts infrastructure-provisioning complexity across multiple clouds behind a single developer portal, enforces architectural and security compliance at admission time, and packages complex environments as one-click "stacks" — making it the canonical wiki production reference for patterns/platform-engineering-investment at regulated-bank scale.

Santander runs >200 critical systems serving >160M customers in >10 countries and processing billions of daily transactions. Pre-Catalyst, provisioning a new service could take up to 90 days and routinely deviated from the architecture reference. Catalyst reduced the full provisioning cycle to hours (best case: minutes), standard provisioning 30 days → 2 days, proof-of-concept preparation 90 days → 1 hour, and consolidated 100+ pipelines into a single control plane (Source: sources/2026-02-26-aws-santander-catalyst-platform-engineering).

Architecture

Catalyst has two load-bearing layers: an in-house developer portal frontend (patterns/developer-portal-as-interface) and a single control plane cluster on Amazon EKS — "the brain of the operation, orchestrating all components and workflows" — that hosts three sub-components:

1. Data-plane claims (ArgoCD)

Managed by ArgoCD, this component is "responsible for continuous synchronization and deployment of application stacks (integrated sets of cloud resources) and configurations, exploring the GitOps concept" — i.e. Git is the source of truth for application state, ArgoCD continuously reconciles observed state to declared state (concepts/gitops).

2. Policies catalog (Open Policy Agent / Gatekeeper)

"A central repository of policies ensuring compliance and security across all operations using Open Policy Agent" — OPA Gatekeeper runs as a Kubernetes admission controller rejecting non-compliant provisioning requests at manifest-submission time (patterns/policy-gate-on-provisioning). Functionally the Kubernetes-native analogue of SCPs in AWS Organizations.

3. Stacks catalog (Crossplane XRDs + Compositions)

"A library of composite resource definitions and Compositions enabling quick and standardized creation of complex environments." Crossplane is used "as a universal resource provisioner ... to manage resources across multiple cloud providers consistently and declaratively" (concepts/universal-resource-provisioning). Composite Resource Definitions (XRDs) + Compositions bundle N cloud primitives behind one high-level custom resource — patterns/crossplane-composition at cloud-infrastructure level, structurally equivalent to patterns/golden-path-with-escapes but for infrastructure rather than K8s service definitions.

Workloads shipped through Catalyst

Three representative workload classes — cited in the source as evidence that Catalyst is a universal platform, not a specialist tool:

  • Generative AI agents stack — "the first success case"; a complete stack for AI agents; shipped implementation time 105 days → 24 hours, dozens of per-environment provisioning tickets eliminated per deployment.
  • Modern data platform — built-in Databricks integration + data lakes + automated ETL + centralized data catalog + segregated experimentation environments; "one of the most complex workloads implemented through Catalyst"; ~3,000 monthly data-experimentation provisioning tickets eliminated.
  • Cloud process orchestration — migration of legacy workflow engines to AWS Step Functions with retry patterns, error handling, and centralized process monitoring.

Reported outcomes

Dimension Before After
Full provisioning cycle Up to 90 days Hours (best case: minutes)
Standard provisioning 30 days 2 days
Proof-of-concept preparation 90 days 1 hour
Pipelines in scope 100+ 1 (single control plane)
Monthly data-experimentation tickets ~3,000 ~0
GenAI agent stack implementation 105 days 24 hours

All from (Source: sources/2026-02-26-aws-santander-catalyst-platform-engineering).

Why this is the canonical large-enterprise instance

Catalyst + ProGlove Insight pin the patterns/platform-engineering-investment spectrum at both ends:

Axis ProGlove Santander Catalyst
Industry SaaS multi-tenant Regulated bank
Isolation boundary AWS account Kubernetes namespace + OPA policies
Guardrail layer AWS Organizations + SCPs + strict IAM OPA Gatekeeper (K8s admission)
Provisioning fan-out CloudFormation StackSets Crossplane Compositions
Application delivery CodePipeline ArgoCD (GitOps)
Team size 3 Not disclosed
Tenant count ~6,000 accounts 200+ critical systems

Same pattern (platform absorbs complexity so app teams ship business logic), same cultural claim (self-service + automation mindset), two different technical substrates.

Seen in

Caveats / what the source doesn't disclose

  • Catalyst operating team size at Santander is not stated.
  • No EKS cluster sizing, no HA topology, no Crossplane provider list, no ArgoCD app-of-apps depth, no OPA Gatekeeper policy examples, no Composition examples.
  • Headline time-to-provision deltas are ratios, not distributions (no p50 / p99, no sample size).
  • No incident retrospective: no Crossplane controller outage, no ArgoCD sync failure, no OPA policy-update gone wrong.
  • Post-PSP-engagement ownership split (AWS ProServe vs Santander in-house) is not stated.
Last updated · 200 distilled / 1,178 read