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

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

4

Payment Hub Architecture

Core Banking

Ledgers

Legacy

Core Banking

Ledgers

Finacle

Payments Hub

Gateways

Payments

Payments Payments

Schemes/3rd Parties

Channels

Payments

BACS FPS CCCCLLink/

ATM/

VISA

Business

Partners

Characteristics

• Integration Services– Routing

– Transformation

– High throughput

• Payments Business Services– Liquidity monitoring

– Liquidity information provision

– Scheme cap monitoring

– Point of control of other services

• Payments Process Execution– Payments process orchestration

– State management

– View of payments state

Decouples ledgers from mechanics of payments processing

5

Payments Hub Justification

• Reduces integration complexity

– SxL problem reduced to S+L

– Complexity reduction since not all schemes connect to all ledger

– Complexity increase due to financial controls

• Supports ledger migration roadmap

• Supports business strategy of acquisition

• Architectural simplicity

– Single payments process

– Use of a single ‘canonical’ data form (ISO20022)

– Master data management issue reduced (CIF, ISCD)

Schemes

Accounting Ledgers / Product Systems

Payments Hub

BusinessLine

Treasury

Mortgage

NewPlatform

Legacy

Inter GL

AcquiredBank

Total Number of Ledgers

6

7

8

9

2008 2009 2010 2011 2012

Cards

Case for a Payments Hub is compelling

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

7

Enrichment Services

Destination Determination

Router

Liquidity Monitor

Flow Control State Machine

Fraud Service(Façade)

Transformation

AML Service(Façade)

Payments Capability Model

Excess Management

Funds ControlPayment Message

Origination

Account Validations

Account Posting

Settlement Control

Accounts

Mandate Management

Intelligent Routing

RepairServices

Almanac

DiaryServices

Capabilities are apportioned but how ?

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

9

Payments Hub Spectrum

•Routing•Transformation

•Payments Almanac•Diary management•Enrichment

PureMiddleware

Payments ‘Engine’

Increasing Functional Richness

•Record Validation•File validation•Payments repository•Bank reconciliation data

•Intelligent scheme routing

•Mandate management•Payment origination•Customer reconciliation data

•Payments state management•Coordination of ‘value-add’ services

•Fraud•AML•Auto-Repair

•End-end process control•Store & Forward

Position on Spectrum

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

11

Service Granularity

• Service granularity refers to the nature of the service interactions between Hub and Ledgers

• Scenario shows a simple 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

Coarse Grained

Fine Grained

12

Technology Selection

Middleware Framework Engine

Pure middleware product supporting messaging/ transformationStateless

Pre-build sub-flows, Payments Repository, Scheme transformations, Stateless/fulGrey box component

Pre-built scheme levelprocessingBlack box component,Stateless/ful

Low technology costRelative low cost implementation

Standard based, Modular

Low implementation cost if‘out of the box’

Building enhanced functions is costly

Customisation can still be extensive

Customisation cycle slowBlack box componentHigh product cost

IBM MQ / Message Broker, Oracle (BEA),

IBM Enterprise Payments Platform, Clear2Pay, Dovetail

Fundtech

Payments Hub Spectrum

13

Canonical Data Zone

• Canonical Data is a standardised representation of the key data– 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 using canonical data

• Ideal world target system should also process payments in the same canonical format

The Canonical Zone

SchemeSpecific Format

SystemSpecific Format

Canonical data standard is best defined as an extended version of a recognised standard

14

Canonical Data Design Issues

• Legacy integration is a neat example– Three necessary transformations

– BACS-Canonical-Legacy

• Package integration– Core banking system vendors offer

scheme modules that already use scheme specific format

– Transform BACS-Canonical-BACS (-Internal)

• Package design principle– Use ‘out of the box’

– Scheme specific interfaces

– Driver against Hub

• Hub design principle– Integration ‘heavy lifting’

– Minimise transformations

– Ideal Canonical Data is an enriched standard form

– Driver against package principle

Universal Scenario• Merger / acquisition• Migration• Different systems for

different product types

BACSSTD18

LegacyFormat

BACSSTD18

The Canonical Zone

15

Architectural Tension

Package Vendor

Client

System Integrator

Low costSpeed to marketFuture proofing

Module SalesCustomisation developmentCountry Specific Modules

Package principleArchitectural Elegance / flexibilityDeliverabilityMinimise risk

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

17

Moving through the Spectrum

•Solution Governance•Policy compliance•Paradigm alignment

Pure Middleware Payments ‘engine’

•Risk & Compliance

•Payments Services Directive

•Product (re-) Selection•Supplier re-selection

Position on Spectrum

Implications of moving through the spectrum are significant

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

19

Liquidity Monitoring

BACS

-40

-20

0

20

40

60

CCCCL

-150

-100

-50

0

50

ATM/LINK/VISA

-100

0

100

200

FPS

0

50

100

150

Net Liquidity Position

-100

0

100

200

Liquidity varies– Intra-day

– Inter-day

– Monthly cycles due to corporate bureaux services

Settlement risk

– Distorted due to Agency Banks

– E.g .Northern Rock

Treasury

– Monitors Cash / Liquidity position periodically

– Plans for Cash Management based on known liquidity position

– Optimises financial investment and borrowing

£(Millions)

Liquidity monitoring and information services are required for pro-active management of liquidity

20

Consequences of Poor Liquidity Management

One lump or two?

Payments Schemes

– Deferred Net Settlement

– Underwritten by the Bank of England

– Require daily settlement payments via 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

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

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

23

Thank You

Merci

Grazie

Gracias

Obrigado

Danke

Japanese

English

French

Russian

GermanItalian

Spanish

Brazilian Portuguese

Arabic

Traditional Chinese

Simplified Chinese

Thai