Peter-Antonius Bramm, SAP and John Velissarios, Accenture present on BizDay at CordaCon 2019.

1. Transition to DLT in RTGS payments
The DLT-Augmented RTGS approach & proof of concept
John Velissarios (Accenture) & Peter Bramm (SAP)
London, June 24, 2019

2. 2© 2019 SAP, Accenture and R3. All rights reserved. Customer
Agenda
1. Motivation
2. Concept and rationale
3. The DLT-Augmented RTGS proof of concept
4. Q & A

3. 4© 2019 SAP, Accenture and R3. All rights reserved. Customer
Motivation
This prototype explores the concept of providing an extra payment channel for central banks
New token-based financial ecosystems such as digital exchanges are now developing organically
These ecosystems need currency tokens issued by central banks to facilitate end to end settlement
The risk for central banks is that they lose control and visibility in this critical area
Central banks need to master this in order to ensure stability of payments and settlement
Here, we set out to show a practical path for central banks to adopt and promote such tokenisation

4. 5© 2019 SAP, Accenture and R3. All rights reserved. Customer
Managing the transition to DLT in payments
The power of DLT
DLT promises to transform many business processes
requiring transactional finality, immutability and security
Digital tokenisation can potentially solve issues around
simultaneous final settlement and counterfeit elimination
Use cases include cross border trade, logistics, smart
contracts … and central banking payments & settlement
The target architecture for central banking scenarios has
been convincingly explored by several central banks
The obstacles to mainstream adoption of DLT are being
steadily overcome e.g. around performance / scalability
Target and transition
It remains unclear how to manage the transition from
conventional RTGS systems to DLT enablement
Attempts to establish DLT payments systems in isolation
from conventional networks are unlikely to succeed
In general, only those new approaches which leverage
existing platforms stand a good chance of succeeding.
Just as PayPal & ApplePay succeed by leveraging
existing payment card networks as a vehicle for change
This is why our DLT payments solution sets out to
integrate with a conventional RTGS, not compete with it

5. 6© 2019 SAP, Accenture and R3. All rights reserved. Customer
DLT-augmented RTGS concept

6. 7© 2019 SAP, Accenture and R3. All rights reserved. Customer
Why Corda?
The benefits of using the Corda platform
1. 1. Transaction privacy & confidentiality:
Only participants involved in a transaction, the counterparties, the notary and any regulatory observers will see that
transaction.
2. 2. Atomic transactions with finality:
Corda transactions are atomic and deterministically final: they either succeed entirely or fail
entirely. When they succeed, they are final and immutable across all participating parties.
3. 3. Scalability:
Corda’s unique data sharing model along with Corda Enterprise’s multi-threading UTXO implementation allow
the platform to scale up to multi-thousand transactions per second.
4. 4. Integration with financial infrastructure:
Function within highly regulated industries and interoperate with governmental systems. This simplifies integration with the
different participants’ existing systems and eases extension to additional transaction types.
5. 5. Offers transparency to regulators:
Observer nodes on Corda enable oversight and monitoring. Observer nodes’ permissions determine when information
should be visible, what information is visible and in what time frame.

7. 8© 2019 SAP, Accenture and R3. All rights reserved. Customer
DLT-augmented RTGS (DaR): guiding principles & implications
Make DLT and conventional
payments systems interoperable
Defend central banks’ control of
the money supply
Ensure complete visibility of DLT
payments to the central bank
Promote robustness in payment
systems via DLT-enablement
 Provide a clear transition path to DLT-enablement
 Maximise realistic chances of adoption
 Tokenise fiat currency, avoid new cryptocurrencies
 Price stability is fundamental to central banks' mission
 Central banks alone can issue & redeem tokens
 Even though DLT payments can travel peer-to-peer
 Central bank control requires maximum transparency
 Centrally monitor decentralised DLT payments
 DLT payment finality depends on the central bank
 Stability of payments is mission-critical to central banks
 Central RTGS is a single point of failure systemically
 DLT distributes operational risk as well as payments

8. 9© 2019 SAP, Accenture and R3. All rights reserved. Customer
1
2b
2b 5
b
3
4
5a
Cash-on-Ledger Lifecycle
Bank 1
Request tokens
DDR on
Ledger
Accounts at
the Issuer
Issue DDR
Bank 1 Bank 2
Transfer DDR
Redeem DDR
Bank 2Central
Bank
2a
2b 4
5b
1
Issue receipt
5a
Reserve AccountsBank 1 Bank 2
3
Key
Reserves Ledger Tx
with DDR
Ledger Tx
no DDR
Banks can only buy tokens
if they have sufficient
reserves at the central
bank
By paying for DDR tokens
using reserves held at the
central bank, the monetary
base is not impacted
DDR represents a claim on
the central bank– it
tokenises actual reserves
DDR is a Digital Depository
Receipt – a digital currency
token – issued by the
central bank
The cycle starts when a
participating bank requests
token purchase at the
central bank
The central bank responds
by moving cash to a central
pool and issuing a token
The central bank responds
by debiting the participant’s
reserve account and
issuing a token
1
2a
2b
Tokens can be transferred
at will between participants
or back to the central bank
3
The central bank responds
by moving cash to a central
pool and issuing a token
Redemption mirrors
issuance – redeem the
token and the participant’s
reserve account is credited
4
5a
5b
Debit reserves Credit reserves

9. 10© 2019 SAP, Accenture and R3. All rights reserved. Customer
DLT-augmented RTGS Proof of Concept
Goal: To showcase the first step in the future of horizontal and vertical
interoperability of payment systems & DLT using SAP & R3 Corda
Actors: Two DLT-enabled commercial banks, two conventional (non-DLT)
commercial banks and one central bank
Processes: Conventional payment via RTGS, direct DLT token transfer
bypassing RTGS, hybrids via RTGS involving one DTL-enabled bank and one
conventional bank
Systems: SAP core banking system (Payment Engine + core banking ledger),
R3 Corda DLT system with nodes for both commercial and central banks

10. 11© 2019 SAP, Accenture and R3. All rights reserved. Customer
6
6 Notify Payment Engine
2 Call Corda API to transfer token
4 Message Bank 2 conventionally
Commercial Bank 1
DLT Payment Adapter
SAP-Corda blockchain integration - example
Showing SAP Payment Engine role in intermediation and control
node
Payment Hub
1 Enter payment – DLT method
2 Call Corda API to transfer token
3 Execute token transfer (unique ID)
4 Message Bank 2 conventionally
2
Central Bank
DLT Payment Adapter
node
RTGS
5 Get confirmation – for oversight
Commercial Bank 2
DLT Payment Adapter
node
Payment Hub
4 Get confirmation; can release funds
6 Reconciliation (optional)
3 Receive token transfer
5 Message RTGS conventionally
Forward message 4
4
Forward message
4 Forward message
Forward message
5
5 Forward message
Transfer token
3
6

11. 12© 2019 SAP, Accenture and R3. All rights reserved. Customer
Central Bank
DLT-augmented RTGS (DaR)
Bank 1
Conventional
Bank 3
Conventional
Demo scenarios
1.1
3.22.4 3.3
0.1 0.2
2.5
Non DLT Enabled – regular RTGS payments
DLT Enabled – CBDC token payments
2.1
0. Conventional RTGS payment
1. Full DLT-enabled payment
2. Mixed – DLT then conventional
3. Mixed – conventional then DLT
1. Bank 1 sends payment to RTGS
2. RTGS forwards to Bank 3
1. Bank 2 transfers tokens to Bank 4
2. Bank 4 gets Corda token paid confirmation
3. Bank 2 messages RTGS digitally (info only)
4. Bank 2 messages Bank 4 to release funds
1. Bank 2 transfers token to RTGS
2. RTGS gets Corda token paid confirmation
3. Bank 2 messages RTGS to release funds
4. RTGS destroys token and so redeems cash
5. RTGS forwards order to Bank 3
1. Bank 1 sends payment to RTGS
2. RTGS issues token to reserve cash
3. RTGS transfers token to Bank 4
4. Bank 4 gets Corda token paid confirmation
5. RTGS messages Bank 4 to release funds
2.3
1.3
1.4
3.5
Bank 2
DLT-augmented
Bank 4
DLT-augmented
3.1
1.2
2.2
3.4
Central Bank
DLT-augmented RTGS (DaR)

12. 13© 2019 SAP, Accenture and R3. All rights reserved. Customer
Key takeaways
Central banks are firmly in the driving seat
This is based on use of DLT tokens issued and controlled by the central bank with no impact on the money supply
DLT must be complementary to RTGS
To achieve this in the short to medium term will require augmentation of RTGS approaches by DLT, not their replacement
The concept already works
Accenture, R3 and SAP have jointly created a proof of concept to show how co-existence could be achieved
Central banks can have the best of both worlds
This approach squares the circle of allowing decentralised payments while retaining or enhancing central bank control
The transition to DLT is a key issue
A key obstacle currently is how to manage the transition from existing RTGS models to DLT-enablement
DLT is becoming mainstream
The obstacles to use of DLT for payments and trade settlement are steadily being mastered

13. Contact information:
John Velissarios
Managing Director, Accenture
Global Blockchain Technology Lead
T +44 7775 406110
john.velissarios@accenture.com
Peter-A. Bramm
Head of Central Banking, SAP
SAP Financial Services Industries Global
T +49 171 3085076
peter-antonius.bramm@sap.com
Thank you

14. 15© 2019 Accenture, SAP and R3. All rights reserved. Customer
© 2019 SAP SE or an SAP affiliate company. All rights reserved.
No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP SE or an SAP affiliate company.
SAP and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP SE (or an SAP affiliate
company) in Germany and other countries. Please see http://global12.sap.com/corporate-en/legal/copyright/index.epx for additional trademark information and notices.
Some software products marketed by SAP SE and its distributors contain proprietary software components of other software vendors.
National product specifications may vary.
These materials are provided by SAP SE or an SAP affiliate company for informational purposes only, without representation or warranty of any kind, and SAP SE or its
affiliated companies shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP SE or SAP affiliate company products and
services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as
constituting an additional warranty.
In particular, SAP SE or its affiliated companies have no obligation to pursue any course of business outlined in this document or any related presentation, or to develop
or release any functionality mentioned therein. This document, or any related presentation, and SAP SE’s or its affiliated companies’ strategy and possible future
developments, products, and/or platform directions and functionality are all subject to change and may be changed by SAP SE or its affiliated companies at any time
for any reason without notice. The information in this document is not a commitment, promise, or legal obligation to deliver any material, code, or functionality. All forward-
looking statements are subject to various risks and uncertainties that could cause actual results to differ materially from expectations. Readers are cautioned not to place
undue reliance on these forward-looking statements, which speak only as of their dates, and they should not be relied upon in making purchasing decisions.