Customer demands for higher levels of service and value, constantly evolving technology capabilities, and stringent regulatory requirements are all powerful forces reshaping retail banking. Built exclusively on AWS, Starling Bank’s 100% cloud-based, mobile-only banking solution satisfies regulators in terms of its resilience, security, and reliability. It also satisfies consumers by giving them greater control over their data, streamlining the account opening process, accelerating payments, and providing access to innovative new services developed from scratch with open APIs, a developer platform, integration with Apple Pay, Google Pay, and Fitbit Pay and a custom backend ledger and payments integrations. Starling Bank is leading the open banking revolution. In this session, learn how Starling Bank delivers value to their customers and innovates at a very fast pace in a sector that can be slow to evolve.
3. Until now people haven’t experienced the same technical innovation from
banks that they have benefitted from everywhere else in their lives.
4. Starling Bank
Tech start-up with a banking licence
100% cloud based, Mobile only
Mastercard debit card
DDs and Faster Payments
Location-enriched transaction feed
Apple Pay, Google Pay, Fitbit Pay...
Spending Insights
International Payments
Open APIs & Developer platform
7. Ethos
• No IT / business separation
• Cross functional teams
• Born agile (and DevOps)
• TDD, automation and ChatOps
• Customer-centric design
• Continuous delivery
8. Core consists of around 20 services each with DB and exposing REST APIs
core services
cards
payments
credit / KYC
mobile APIs open APIs partner APIs mgmt APIs
monitoring
management
analytics
secrets
9. The back-end
• Java services in Docker on CoreOS
• Jetty, Guice, Guava, Hystrix
• REST (JAX-RS) APIs throughout
• Postgresql databases
• A bit of a NIH maybe - homegrown:
• SQL database access layer
• Configuration, command line, app framework, background processing...
• No Spring, no JEE app servers, no distributed transactions
10. Postgres
• Half a century of research
• Modern SQL: Markus Winand
• Check constraints
• Row locking: select … for update nowait
• Logical Replication: WAL shipping
11. We built everything in the cloud
• Back-end APIs for mobile apps
• Open APIs for developers and partners
• Console for CC and operations
• Back-end ledger, payments
• Connectivity for cards, FPS
• Notifications, messaging
• Customer and fraud analytics
• Entirely in AWS
12. The infrastructure
• AWS for IaaS – Amazon Elastic Compute Cloud (Amazon EC2),
Amazon Virtual Private Cloud (Amazon VPC), Amazon Relational
Database Service (Amazon RDS), AWS CloudFormation
• 1:1 service instance to EC2 instance, each service is ASG
• Tooling in Go, Python, Node.js, Java
• Prometheus for monitoring
• ELK for log aggregation
• Vault for secrets management
• PagerDuty for incident alerting
13. Resilient architecture in the cloud
• Immutable infrastructure
• Crash-safe
• Chaos engineering
• Practiced incident response
14. Self-contained systems
• Each has a database
• Partial degradation
• Data flow across systems
• Beware the distributed monolith
15. DITTO
• Do Idempotent Things To Others
• Async + idempotence + retry
• Immutability
• Database queues
• Resilience to bugs
16. Continuous delivery of back-end
• Continuous deployment to non-prod, sign-off into prod
• Auto build, dockerise, test, scan, deploy < 30m
• In first 475 days of production environment
• 322 releases of software (~ 1 per weekday)
• 170 releases of infrastructure (~1 per 2 weekdays)
17. Tools for continuous delivery
• Roller platform service to orchestrate releases
• github.com for version control and pull requests
• quay.io for docker registry and security scans
• Artifactory for artefact management (jars, npm, docker, pip)
• TeamCity for CI / CD
• codecov.io for code coverage metrics
• Slack for basically everything
24. In the cloud of course…
• Starling architecture: stateless independent services in AWS
• API service, OAuth service, Dev Portal
• Infra as code & docker yield options for sandbox environments
• Open API bridges to internal Starling APIs for control of lifecycle
• We use OAuth2 as basic but have plans to evolve
25. • Payment directly from bank account
• Aggregation / finance management
• Directly expose data for credit checks
• Perform actions on payment (e.g. loyalty)
• Inference from spending
What could I do with it?
27. Standardising endpoints
If you meet our spec we can onboard you quickly, if you don’t meet these specs we
cannot prioritise your integration - we do not do partner specific customisations.
There are three behaviours we want to standardise:
1. Product Details
2. Auth Code Exchange
3. Refresh Token
Why do we want to do this?
1. Quality restrictions - we want to focus on a high-level user experience. This is
good for us and our partners because a nicer UX can lead to higher conversions
and when you succeed, so do we!
2. Scalable - it allows us to onboard partners quickly.
28.
29. What’s next?
• Fast enough to deliver loads of UK firsts
• first to deliver in-app provisioning of Apple Pay
• first UK mobile-only current account available to general public
• first challenger to deliver ApplePay, GooglePay, overdrafts…
• first UK bank with PSD2-capable open APIs
• This is only the beginning
• Big effort to get to the starting line
• Lots to come