Open Group Conference 2011 - The Canonical Data Zone
IET NW Region - Payment Hub Design
1. Payment Hub Design
(…or how IT helps solve the credit crunch)
Gary Farrow
IET / BCS 7th Sept 2010
2. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
2
3. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
3
4. Payment Hub Architecture
Schemes/3rd Parties
Link/
Characteristics
Business
• Integration Services
BACS FPS ATM/ CCCCL Partners
VISA
– Routing
– Transformation
– High throughput
Gateways Channels
• Payments Business Services
– Liquidity monitoring
Payments Payments – Liquidity information provision
– Scheme cap monitoring
Payments Hub – Point of control of other services
Payments
• Payments Process Execution
Payments
– Payments process orchestration
Core Banking Core Banking
Ledgers Ledgers – State management
Legacy Finacle – View of payments state
Decouples ledgers from mechanics of payments processing
4
5. Payments Hub Justification
• Reduces integration complexity
Schemes – SxL problem reduced to S+L
Payments Hub – Complexity reduction since not all
schemes connect to all ledger
– Complexity increase due to financial
controls
Accounting Ledgers / • Supports ledger migration
Product Systems roadmap
• Supports business strategy of
Business New Acquired acquisition
Treasury Legacy
Line Platform Bank
• Architectural simplicity
Mortgage Cards Inter GL – Single payments process
– Use of a single ‘canonical’ data form
Total Number of Ledgers
(ISO20022)
9
– Master data management issue
8
reduced (CIF, ISCD)
7
6
2008 2009 2010 2011 2012
Case for a Payments Hub is compelling
5
6. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
6
7. Payments Capability Model
Diary Mandate Intelligent
Flow Control State Machine
Services Management Routing
Destination Enrichment Repair
Router Almanac
Determination Services Services
Settlement
Transformatio AML Service Fraud Service Excess
Control
n (Façade) (Façade) Management
Accounts
Payment
Account Account Liquidity
Funds Control Message
Validations Posting Monitor
Origination
Capabilities are apportioned but how ?
7
8. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
8
9. Payments Hub Spectrum
Position on Spectrum
Pure Payments
Middleware ‘Engine’
•Routing •Record Validation •Payments Almanac •Payments state •Mandate •Intelligent scheme
•Transformation •File validation •Diary management management management routing
•Payments •Enrichment •Coordination of •Payment
repository ‘value-add’ services origination
•Bank •Fraud •Customer
reconciliation data •AML reconciliation
•Auto-Repair data
•End-end process
control
•Store & Forward
Increasing Functional Richness
9
10. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
10
11. Service Granularity
• Service granularity refers to
the nature of the service
interactions between Hub and
Ledgers
Coarse Fine Grained • Scenario shows a simple
Grained payment pattern
• Granularity affected by:
– Capability of Hub
– Nature of product systems
• Modern banking packages
have rich capability
– Coarse grained services
• Legacy systems provide
disaggregated services
– Fine grained services
11
12. Technology Selection
Payments Hub Spectrum
Middleware Framework Engine
Pure middleware product Pre-build sub-flows, Payments Pre-built scheme level
supporting messaging/ Repository, Scheme processing
transformation transformations, Stateless/ful Black box component,
Stateless Grey box component Stateless/ful
Low technology cost Standard based, Low implementation cost if
Relative low cost Modular ‘out of the box’
implementation
Building enhanced functions is Customisation can still be Customisation cycle slow
costly extensive Black box component
High product cost
IBM MQ / Message Broker, IBM Enterprise Payments Fundtech
Oracle (BEA), Platform, Clear2Pay, Dovetail
12
13. Canonical Data Zone
• Canonical Data is a standardised
Scheme representation of the key data
Specific Format – ISO2002 credit / debit transfers
– Base24 real-time payments
• Canonical Data Zone is the
architectural layers that make
use of such data
– Objective: Reuse of common
processing steps
• Hub should process payments
The Canonical Zone
using canonical data
• Ideal world target system should
System also process payments in the
Specific Format same canonical format
Canonical data standard is best defined as an extended version of a recognised standard
13
14. Canonical Data Design Issues
• Legacy integration is a neat example
BACS
STD18 – Three necessary transformations
– BACS-Canonical-Legacy
• Package integration
The Canonical Zone – Core banking system vendors offer
scheme modules that already use
scheme specific format
– Transform BACS-Canonical-BACS (-
Internal)
• Package design principle
BACS – Use ‘out of the box’
STD18 – Scheme specific interfaces
Universal Scenario – Driver against Hub
• Merger / acquisition Legacy • Hub design principle
• Migration Format – Integration ‘heavy lifting’
• Different systems for – Minimise transformations
different product – Ideal Canonical Data is an enriched
types standard form
– Driver against package principle
14
15. Architectural Tension
Package
Client
Vendor
Low cost Module Sales
Speed to market Customisation development
Future proofing Country Specific Modules
Package principle
System Architectural Elegance / flexibility
Integrator Deliverability
Minimise risk
15
16. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
16
17. Moving through the Spectrum
Position on Spectrum
Pure Middleware Payments ‘engine’
•Product (re-) •Risk & •Solution Governance
Selection Compliance •Policy compliance
•Supplier re- •Payments •Paradigm alignment
selection Services
Directive
Implications of moving through the spectrum are significant
17
18. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
18
19. Liquidity Monitoring
£(Millions)
BACS CCCCL
Liquidity varies
60 50
– Intra-day
40
20
0
-50
– Inter-day
0
-20 -100
– Monthly cycles due to corporate
-40 -150
bureaux services
ATM/LINK/VISA FPS Settlement risk
200 150 – Distorted due to Agency Banks
100 100
– E.g .Northern Rock
0 50
-100 0
Treasury
– Monitors Cash / Liquidity position
Net Liquidity Position periodically
200 – Plans for Cash Management based
100 on known liquidity position
0 – Optimises financial investment and
-100 borrowing
Liquidity monitoring and information services are required for pro-active management of
liquidity
19
20. Consequences of Poor
Liquidity Management
Payments Schemes
– Deferred Net Settlement
– Underwritten by the Bank of England
One lump or
– Require daily settlement payments via two?
Real Time Gross Settlement
Once settlement figure are known scheme
participating Banks have ~20 minutes to make a
CHAPS payment
Missing a settlement payment is not
desirable
– Repetition will result in scheme expulsion
– CxO will be ‘invited for tea’ at the Bank of
England
Payment Hub is the architectural component to provide liquidity monitoring services
20
21. Agenda
• Payment Hub Overview
• Capability Model
• Payments Hub Spectrum
• Design Issues
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Traversing the Spectrum
• Liquidity Problem
• Review
21
22. Review
• Payment Hub Overview
Understand what a Payments Hub is
Benefits it can provide
• Capability Model
• Introduced the Payments Hub Spectrum
• Design Issues in placement on the Spectrum
– Service Granularity
– Technology Selection
– Canonical Data Zone
• Issues in traversing the Spectrum
• Liquidity Problem
– How a Hub can monitor liquidity
• Solved the Credit Crunch?
Not quite…..
But by designing Payments Hubs for our major banks I hope IT make a small but important
contribution
22
23. Thai
Traditional Chinese
Russian
Gracias Spanish
Thank You English
Arabic
Merci
French
Obrigado
Brazilian Portuguese
Grazie Danke
Italian German
Simplified Chinese
Japanese
23