0% found this document useful (0 votes)
59 views10 pages

Cloud Native Architecture for Banking

The document discusses the importance of Cloud Native Architectures for digital banking, emphasizing their ability to leverage cloud capabilities for improved scalability, performance, and cost efficiency. It outlines the transition from traditional monolithic applications to microservices-based architectures, highlighting key design principles and deployment patterns. Additionally, it presents a vision for future banking platforms that integrate various digital touchpoints and services through APIs and microservices.

Uploaded by

marcelorgs
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
59 views10 pages

Cloud Native Architecture for Banking

The document discusses the importance of Cloud Native Architectures for digital banking, emphasizing their ability to leverage cloud capabilities for improved scalability, performance, and cost efficiency. It outlines the transition from traditional monolithic applications to microservices-based architectures, highlighting key design principles and deployment patterns. Additionally, it presents a vision for future banking platforms that integrate various digital touchpoints and services through APIs and microservices.

Uploaded by

marcelorgs
Copyright
© All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd

Digital Banking Architecture - Cloud Native Architectures for a Digital Bank

June 2018
Cloud Native Architectures are essential
Cloud Native architectures follow design patterns that embrace the underlying characteristics of the Cloud – resulting in
processes and workflows that fully take advantage of the platform

Challenges with Traditional Applications Architectures Key Considerations for developing Cloud Native Applications

• As organizations migrate applications and Eventual


CAP Theorem ACID vs BASE Microservice
Consistency
infrastructure to the cloud, they are beginning to
realize that traditional applications
architectures are unable to utilize the full
potential and capabilities offered in the cloud.
12 Factor Deployment Guiding
• Secondly, bottlenecks and poor end user SQL & NoSQL
App Patterns Principles
performance risks emerge when assuming that
‘unlimited capacity’ alone would solve the problem

• Costs can quickly spiral out of control when


traditional architectures and deployment models App Design Horizontal Immutable &
are attempted to be leveraged in the cloud REST API
Patterns Scalability Idempotent

And More…..

“Cloud native architectures take full advantage of on-demand delivery, global deployment, elasticity, and
higher-level services. They enable huge improvements in developer productivity, business agility, scalability,
availability, utilization, and cost savings”

- Adrian Cockroft, VP of Cloud Architecture, AWS (Ex BatteryVentures/Netflix/eBay/Sun)

Copyright © 2018 Deloitte LLP. All rights reserved. 2


Cloud Native Architecture design principles
A cloud native application involves multiple services and each service is loosely coupled, elastic, resilient, composable and
infrastructure agnostic

Dimension Design Principles

What looks like a single application to the end user is actually delivered by a set of co-
Multiple Services operating services

Locate and communicate with other services dynamically at runtime. Independently deployable
Loosely Coupled & replaceable

Elastic Scale-up or scale-down independently enabling automatic scaling on-demand

Run reliably & predictably in spite of transient issues in the cloud involving network, variable
Resilient
loads and capacity

Composable Designed to allow it to be part of other applications. Uniform and discoverable API

Infrastructure Agnostic Decoupled from infrastructure constraints and free to move as required.

Responsive to Business
Updated & deployed frequently and independently, with zero down-time
Changes

Copyright © 2018 Deloitte LLP. All rights reserved. 3


The digital banking platform of the future
A future banking platform will be a hybrid between on premise and cloud ecosystems, leveraging API frameworks and
microservices architecture

Service &
Processing Fintechs Developer
Mobile App Mobile Web Web In-App SMS eMail Social ATM Kiosk Branches Communities
NOTIFICATION SERVICES BACK OFFICE DELIVERY CHANNELS 3 R D PARTY
DIGITAL TOUCHPOINTS
(BANK) PLATFORM/DEVELOPERS

API HUB
Service API API API API
iPaaS
Discovery Caching Logging Throttling Mgmt.
PAYMENTS HUB
DIGITAL BANKING PLATFORM
Container-based Card Servicing Financial &
Private Fraud
Microservices are enable banking
and
Management
Sales Retirement Provides a seamless
Collections Planning
experience across all
Microservices Architecture

products across lines of


Capital Corporate Online/Mobile Trust and
business to share common Markets Lending Banking Investments
channels (mobile, web,
services and data, and Storefront tablet, etc.) in a
Automated Consumer
(POS)
Treasury Investment SWIFT
easily scale via open APIs Investing Lending
Management
Management management continuous and non-
siloed way

API’s
API’s

Lending Merchant
Trust and Commercial
Services and Transaction
Investments Lending
Operations Processing
Common Operational
Savings Servicing & Deposit
Administrative and Regulatory
Account Support Operations
Services Risks
Visa/
Checking Consumer Deposit and Payment Payments hub and
API’s enabling Account Loans MC
Self-Service Operations network
integration among Analytics &
Authentication
Transaction Reversals & enabling banks
& Marketing
microservices as well Reporting
Authorization
Operations Disputes
to access money
as with 3rd party markets, facilitate
touch points Container-based deployment
payments, and
Clearing
House meet regulatory
API’s requirements
DATA SCIENCE Data Science tier
Customer providing data ingest, Computational
NETWORKS
Insights governance, quality, Nodes
Computational Big Data Analytics AI/ ML Predictive Analytics
Log Nodes machine learning and
Nodes Data Warehouse
predictive capabilities
PUBLIC CLOUD PRIVATE CLOUD

Sample Independent Services Sample Common Business Services

Copyright © 2018 Deloitte LLP. All rights reserved. 4


Building blocks of a future banking platform
A banking platform can comprise of multiple microservices, hosted in containers. Each microservice is standalone, while
leveraging a common set of business services. All microservices can be reused across any business product and channel

Retirement
Fee Distributor Fund
Brokerage Trust Planning
Management Maintenance Reporting
Counsel
Clearance Syndicated
Financial Corporate Loan Tax
and Payment FX Trading Loan
Guidance Underwriting Servicing Reporting
Settlement Management
Fraud
B2B/B2C
Branch Detection Loan Sales / Transaction
Channels/
Locator and Management Origination Reporting
Touchpoints
Resolution
Investment
Portfolio Closing / Incentives and Process Fee Lending
Derivatives Risk &
Construction Booking Compensation Management Services
Compliance

Billing and Service Corresponde


Transaction Portfolio
Remittance Request Fulfillment nt Bank
Accounting Management
Processing Management Fulfillment
Disputes
Institutional Portfolio
Commercial Reporting Wire Transfer Risk
Trading Trust and Order
Underwriting and Services Management
Custody Management
Resolution
Account Certificates Central Cash
Deposits Reporting Cross-Selling
Management of Deposit Handling

Servicing
Automated Account Credit Internet/ Payment Grievance
and
Transfer Processing Compliance Intranet Processing Management
Collections
Document/
Account Check Payments Authorize
Image Fund Transfer
Opening Processing Execution Transaction
Management
Customer
Advisory Account Self- Audit Log Customer Product
Promotions Relationship
Services Service Management Verification Definition
Management

Sample Independent Services Common Business Services

Copyright © 2018 Deloitte LLP. All rights reserved. 5


Illustrative Use Case: Credit Card
1 Swipes Card
Batch request of all sales Key Processes
11 to receive payment Service &
Authorization (Steps 1 - 10 )
Processing
 Merchant connects to Acquirer Bank’s API Hub for sale authorization
CARDHOLDER 20 10 Receives purchase MERCHANT BACK OFFICE  Acquirer Bank uses Rest APIs to route request to card issuer bank
2 9 19 A PI 12 through the card network
REST  Issuer Bank sends authorization to acquirer if valid credit is available
3 13  Acquirer bank authorizes merchant
API HUB
ACQUIRER Service API Logging / API REST API
BANK iPaaS
Discovery Caching Mgmt. Batching (Steps 11 - 12 )
PAYMENTS HUB
8 18  At the end of each day merchant transmits a batch request of all
21 REST API
7 4 authorized sales to receive payment
DIGITAL BANKING PLATFORM
17 14 Clearing (Steps 13 - 18 )
Capital Corporate
Online/
Mobile
Trust and
Investmen
Clearance
& Payment
 Acquirer bank uses Rest APIs to send batch request to card network
Markets Lending
Transactio Storefront
Banking ts Settlement  Each sale is routed to appropriate issuing bank
Treasury
n (POS)
Mgmt.
Sales  Issuer bank transfers amount to the acquirer bank
Accounting Lending Mgmt.
Card Services Commerci Deposit <Financial
Fee Mgmt.
Operations and al Lending Operations
Operations Operationa Transactions Funding (Steps 19 - 20 )
Customer l and Deposit Fraud Processor
Verification Servicing
REST API

Regulatory Mgmt.
Consumer Risks Authorize
#5>  Acquirer bank transmits payment to the merchant
Account
Self- Reporting
Payments
Transactio CARD
Mgmt. Execution
Service n NETWORK
Common General Ledger Management(Steps 21 - 23 )
Admin.

REST API
Services REST API
6 5  All transactions are recorded in the cloud database through microservices
REST API that connect using Rest APIs
16 15
22
Authorize if credit
DATA SCIENCE available
Big Data Analytics Customer Insights
 Independent microservices (e.g. Transaction Accounting, Fee
Management and Clearance & Payment Settlement) are used by specific
REST API

REST API processes (Clearing process in this case)


23  Authorization, Batching, Funding and General Ledge Mgmt. processes
PUBLIC / PRIVATE Data Computational ISSUER
use a set of shared microservices (Account Management, Customer
CLOUD BANK Verification, Reporting, payments Execution and Authorize Transaction)
Warehouse Nodes

Process: Authorization Batching Clearing Funding General Ledger Management

Legend:
Sample Independent microservices
Acquirer: A bank that processes and settles a merchant's credit card transactions with the help of a card issuer
Copyright © 2018 Deloitte LLP. All rights reserved. Cardholder: The owner of a card that is used to make credit card purchases Sample Shared microservices 6
Issuer: A financial institution, bank, credit union or company that issues or helps issue cards to cardholders Microservices not used in the credit card process
Transformation from Monolithic to Microservice Architecture
Moving from a monolithic architecture to a microservices based architecture involves splitting the application into a set of
independent services
Monolithic Applications Microservices Applications

Provides a seamless API


Credit Card Mortgage experience across all Gateway Fintechs
channels (e.g. mobile)
Request in a continuous and Rest
Request
Registration non-siloed way API Dispute
Single-tiered large Registration Developer
Mgmt.
s/w app having UI & Communities
data access code Rest
combined in a single Background Background API Hub API Loan
Mobile App
program Verification Verification Disbursal
Rest
Modules Rest
API Request
performing the Register API Account
Issuance Loan Amount
same functionality Statement
Disbursal
are duplicated ATM Rest
across the
Transaction API Loan
applications Rest
Authorization A/C Statement Mgmt.
API Backgroun
d Check
Branches
Payment Dispute Web UI
App designed to Clearance Management Rest
execute complete API Payment
function instead of Rest Clearance
particular task API
A/C Loan Default Insurance
Statement Management
Desktop
Rest
App comprises of Independently Authorize
API
multiple tightly deployable small Transaction
coupled modules modular services
(e.g. BV, Statement, accessible via APIs
etc.)

Instead of building large, monolithic applications, the goal should be to split applications into a set of
smaller, interconnected services resulting in a highly efficient and loosely coupled ecosystem

Copyright © 2018 Deloitte LLP. All rights reserved. Common modules across applications 7
Cloud Native Application Design and Deployment Patterns
An App Design and Deployment Pattern is a consistent and repeatable way of achieving an outcome tied to scalability,
performance, availability and resiliency of the entire distributed system

The following Cloud Native patterns were identified as part of a recent client engagement within the Enterprise and Cloud Architecture group

1 Messaging 10 Webservices (SOAP, REST etc.) 19 Data as a Service

2 Caching 11 Load Balancing 20 Analytics/Reporting

3 Event Sourcing 12 Auto Scaling 21 Archiving (Storing and Purging)

Command Query Response 13 Time-based processing/Scheduling


4 22 Container based deployment
Segregation

5 Circuit Breaker 14 Public to Internal integration 23 AI/Machine learning integration

6 Service Discovery 15 Cloud Security and Encryption 24 Serverless deployment

7 Database per service 16 Data Redaction/Masking 25 IoT Framework

8 Sharding 17 Logging and Dashboarding 26 Data Pipelines

9 Secrets Management 18 File System Integration 27 Batch Processing

Nine patterns from the above list were delivered in Phase 1 supported by actual examples that can be
utilized/leveraged by solution architects and developers

Copyright © 2018 Deloitte LLP. All rights reserved. 8


Design Pattern Snapshot - Event Sourcing
Events as a source of truth, triggers to transactions and eventual consistency models

Illustrative
Key Attributes
App 1 - Orders App 2 - Billing App 3 - Shipping App 4 - Notification  Microservices-based applications are designed to
accommodate the following actions:
Subscrib Subscrib Subscrib  Coordinating multiple transactions into a single
e Event e Event e Event
transaction
Publish Publish  Enabling an eventually consistent system
Event Event
 Preserving application independence in a cloud
Event Store environment
Topic A Topic B Topic C Persiste
Order
d Events
received  Event sourcing is the pattern that leverages events as
inputs and outputs of transactions
 Events can be published and subscribed to
Use Case Details
 Events are immutable
Distributed Transactions Enabling events to complete transactions
 Events are stored in an event store for auditing and
Refresh of Distributed Bringing the system into an eventually consistent logging
Transactions state
 Events can be leveraged for multiple use cases in a
Having a master node distribute actions to child
Task Distribution to Nodes distributed highly available system
nodes

Determining actions to recover from transaction


Failure Recovery
failure

Logging & Auditing Understanding transaction flow and related insights

Copyright © 2018 Deloitte LLP. All rights reserved. 9


Authors

Seth Montgomery Ranjit Bawa Chris Thomas Ritesh Biswas Sibu Kutty
Principal – Minneapolis Principal – New York Senior Manager - Chicago Senior Manager - Parsippany Senior Manager - Chicago
smontgomery@[Link] rbawa@[Link] chrthomas@[Link] rbiswas@[Link] sikutty@[Link]

Maxwell Kruger James Carney Matt Butler Marya Zarkout


Manager – Chicago Manager – New York Analyst – McLean Analyst – New York
mkruger@[Link] jamcarney@[Link] mattbutler7@[Link] mzarkout@[Link]

Nandan Muralidharan Sanket Kothari Satyabrata Chayani Aman Chowdhary


Senior Consultant - Bengaluru Consultant - Mumbai Consultant - Bengaluru Consultant - Bengaluru
namuralidharan@[Link] sankothari@[Link] schayani@[Link] amchowdhary@[Link]
Copyright © 2018 Deloitte LLP. All rights reserved. 10

You might also like