Blog

4 min read
Home » Blogs

Platform Engineering for Banks: Building Internal Developer Platforms in Regulated Environments

Platform engineering for banking. Internal developer platforms, golden paths, and self-service infrastructure that satisfies regulatory requirements.

Banks have more engineers than ever, but those engineers spend more time on infrastructure than on features. A developer at a typical bank waits days for infrastructure provisioning, weeks for security approvals, and months for compliance reviews. Platform engineering is the discipline of converting that wait time into self-service.

For banks, platform engineering has an additional constraint: regulatory compliance. Every infrastructure decision must satisfy audit requirements. An internal developer platform that makes engineers productive while maintaining compliance is the difference between scaling engineering velocity and drowning in operational overhead.

Who Is This Guide For?

This guide is for bank CTOs, platform engineering leads, and engineering managers building internal developer platforms. If your engineering team is growing and you need to maintain velocity without sacrificing compliance, this is for you.

By the End of This, You’ll Know…

  • Why platform engineering matters more at banks than at tech companies
  • How to design golden paths that enforce compliance without blocking developers
  • The architecture patterns for self-service infrastructure in regulated environments
  • How to measure platform engineering success with concrete metrics

Why Platform Engineering in Banking

Banks face a unique tension: engineers need to move fast to ship features, but compliance requirements demand careful control over infrastructure. Without platform engineering, this tension creates one of two failure modes:

  1. Slow compliance: Every infrastructure change requires manual review. Engineers wait days for approvals. Velocity drops.
  2. Fast non-compliance: Engineers provision infrastructure freely, ignoring compliance requirements. The audit reveals gaps.

Platform engineering resolves this tension by encoding compliance requirements into golden paths — pre-approved infrastructure patterns that engineers can use without manual review.

Golden Paths: Compliance as Code

A golden path is a pre-approved way to build and deploy a specific type of service:

  • Infrastructure template: Pre-configured Terraform or Pulumi modules that satisfy compliance requirements
  • CI/CD pipeline: Pre-built deployment pipeline with security scanning and compliance checks
  • Observability stack: Pre-configured logging, monitoring, and alerting that meets audit requirements
  • Access control: Pre-defined roles and permissions that satisfy least-privilege requirements

Example: Deploying a new API service

Without golden paths:

  1. Engineer provisions infrastructure manually
  2. Configures networking manually
  3. Sets up logging manually
  4. Requests access from compliance team
  5. Deploys manually
  6. Waits for audit review

With golden paths:

  1. Engineer selects “API Service” from the platform catalog
  2. Fills in service name, team, and data classification
  3. Platform provisions everything automatically
  4. Engineer deploys code through the pre-built pipeline

Self-Service Infrastructure

Service Catalog

A service catalog provides a menu of available golden paths:

  • API Service: For REST or gRPC APIs
  • Data Pipeline: For batch and streaming data processing
  • Database Service: For PostgreSQL, MySQL, or Redis databases
  • ML Model Service: For model training and inference

Self-Service Portal

A web-based portal where engineers can:

  • Browse available golden paths
  • Provision new infrastructure
  • View running services and their status
  • Request access to existing services

Automation Platform

Behind the portal, an automation platform orchestrates:

  • Infrastructure provisioning via Terraform or Pulumi
  • CI/CD pipeline creation via GitHub Actions or GitLab CI
  • Monitoring setup via Prometheus and Grafana
  • Compliance validation via policy-as-code

Compliance Integration

Policy-as-Code

Compliance requirements are encoded as policy-as-code:

  • Network policies: All services must use private subnets
  • Encryption: All data at rest must use AES-256. All data in transit must use TLS 1.2+.
  • Access control: All production access must use break-glass procedures
  • Logging: All access to sensitive data must be logged

Automated Compliance Validation

Every infrastructure change is automatically validated against compliance policies:

  • Pre-deployment: Terraform plans are validated against policies before apply
  • Post-deployment: Infrastructure is scanned against policies after deployment
  • Continuous: Running infrastructure is continuously validated

What You Can Actually Use Today

  • Backstage: Open-source developer portal by Spotify
  • Port: Commercial developer portal with golden path support
  • Kratix: Platform-as-a-product framework for Kubernetes
  • Crossplane: Kubernetes-native infrastructure provisioning

FAQ

How long does it take to build an internal developer platform for a bank?

A minimum viable platform takes 6-12 months. A mature platform takes 18-24 months. Start with one golden path and expand based on team needs.

Do we need a dedicated platform team?

Yes. One platform engineer per 10-15 developers is a typical ratio. The platform team builds and maintains golden paths, not individual services.

How do we handle exceptions to golden paths?

Exceptions require review by the platform team and compliance team. Track exceptions in a central registry. Review exceptions quarterly to identify patterns that should become new golden paths.

We help banks design and build internal developer platforms that maintain compliance while enabling developer productivity. If you are building a platform team, get in touch.