71% found this document useful (7 votes)
1K views40 pages

SAP Multi-Bank Connectivity - Architecture - Introduction - 2018

The document discusses SAP's multi-bank connectivity architecture. It describes the architecture layers, business processes, system overview, protocol layers, and application layer with examples of ISO 20022 message types.

Uploaded by

Juan Colme
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
71% found this document useful (7 votes)
1K views40 pages

SAP Multi-Bank Connectivity - Architecture - Introduction - 2018

The document discusses SAP's multi-bank connectivity architecture. It describes the architecture layers, business processes, system overview, protocol layers, and application layer with examples of ISO 20022 message types.

Uploaded by

Juan Colme
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 40

SAP Multi-Bank Connectivity

Architecture Overview
SAP
2018

PUBLIC

Partner logo
Disclaimer

The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the permission
of SAP. Except for your obligation to protect confidential information, this presentation is not subject to your license
agreement or any other service or subscription agreement with SAP. SAP has no obligation to pursue any course of
business outlined in this presentation or any related document, or to develop or release any functionality mentioned therein.
This presentation, or any related document and SAP's strategy and possible future developments, products and or platforms
directions and functionality are all subject to change and may be changed by SAP at any time for any reason without notice.
The information in this presentation is not a commitment, promise or legal obligation to deliver any material, code or
functionality. This presentation is provided without a warranty of any kind, either express or implied, including but not limited
to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement. This presentation is for
informational purposes and may not be incorporated into a contract. SAP assumes no responsibility for errors or omissions
in this presentation, except if such damages were caused by SAP’s intentional or gross negligence.
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.

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 2


Architecture Layers
Business Process: Settle & Pay, Reconcile

Corporate
FSN
Cloud
Bank
1 2 Corporate
FSN
Cloud
Bank

Payment Run

Payment Create Intra-day


Bank Statement
Payment Bank Statement

Bank Statement

Process Payment
(Backend)
Upload Bank Statement
Payment Status Report
for information Create End-of-day
Bank Statement
Payment Status Report
Bank Statement
Continue Payment
Processing
(Backend)
Bank Statement
Update BCM Status
(e.g. Received by Bank) Payment Status Report

Upload legal binding


Bank Statement

Update BCM Status


(e.g. Accepted by Bank)

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 4


System Overview

Infrastructure: Technical Communication:


• Based on SAP HANA Cloud Platform • Various connectivity options (e.g. https, sftp)
• Virtualization and scalability • High security (multiple security layers)
• Test and production systems • Reliable messaging: “at-least-once” quality
• Multi-tenancy with strict isolation • Bidirectional with multiple communication patterns
• Multiple services, e.g. Persistency, Identity (e.g. push-push, push-pull)
Management, Key Management • Integration capabilities e.g.:
• (Java) application development on-top • Routing
• Mapping
• Security Protocol Mediation
© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 5
Protocol Layers
(roughly based on OSI layers)

Protocol Layer Used technology Remarks


Technology ………. Application

6. Application Predefined set of industry Mapping done in the ERP


standard message formats1 System
5. Security PKCS#7 -or- PGP -or- Certificates exchanged during
XML Digitial Signature onboarding
4. Message Message format Message format supports
technical header, security and
bulks
3. Session TLS-https-WS / XI -or-
SSH-sftp-file -or- AS2
2. Transport TCP/IP (none)

1. Network/Physical Internet (none)

1 = e.g.: ISO20022 (native, CGI, SEPA), SAP IDoc (PEXR), Swift MT


2 = available in pull scenario for corporates; in discussion for banks
© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 6
Application Layer
Example: ISO 20022 Message Types

SAP CDG
▪ 15 Selected Banks: E.g.: HSBC, Citibank, RBS
▪ Purpose: Develop mappings of CGI guidelines
of all 6 CGI profiles to SAP internal Data Fields
▪ Deliverables: Individual maps – DMEE/PMW
XML Format, PI XML Schema, Excel
Spreadsheet, or other
ISO20022 CGI
▪ Financial institutions and non-financial
institutions (corporate organizations,
corporate associations, etc.)
▪ Purpose: Simplify implementation for
corporate users, focus on localization (country
specific rules and laws)
▪ Deliverables: CGI message implementation
templates (profiles)
ISO20022
▪ ISO TC68 (Financial Services) members, see
http://www.iso20022.org/
▪ Purpose: Common platform for development
of messages
▪ Deliverables: UML based modeling
methodology, central directory, 20022 XML

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 7


Application Layer
Example: ISO 20022 pain.001 Payment with two Transactions
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03" <CdtTrfTxInf>
(continued)
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <PmtId>
xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 <EndToEndId>
sap_pain.001.001.03.xsd"> E2EID-SAP-EBA-SCT-812-001-A1
</EndToEndId>
<CstmrCdtTrfInitn> </PmtId>
<GrpHdr> <Amt>
<MsgId>MID-SAP-EBA-SCT-812-001</MsgId> <InstdAmt Ccy="EUR">5.10</InstdAmt>
<CreDtTm>2009-10-27T08:30:47Z</CreDtTm> </Amt>
<NbOfTxs>2</NbOfTxs> <CdtrAgt>
<InitgPty> <FinInstnId>
<Nm>Deutsche Wunschbank AG</Nm> <BIC>DRESDEFFXXX</BIC>
</InitgPty> </FinInstnId>
</GrpHdr> </CdtrAgt>
<Cdtr>
<Nm>DEGUDENT GMBH</Nm>
<PmtInf> </Cdtr>
<PmtInfId>PID-SAP-EBA-SCT-812-001-A</PmtInfId> <CdtrAcct>
<PmtMtd>TRF</PmtMtd> <Id>
<ReqdExctnDt>2009-11-26</ReqdExctnDt> <IBAN>DE27500800000090521500</IBAN>
<Dbtr> </Id>
<Nm>Max Mustermann</Nm> </CdtrAcct>
<RmtInf>
</Dbtr>
<Ustrd>VZW unstrukturiert
<DbtrAcct> SAP-EBA-SCT-812-001-A1</Ustrd>
<Id> </RmtInf>
<IBAN>DE49900100000001000023</IBAN> </CdtTrfTxInf>
</Id> </PmtInf>
</DbtrAcct>
<DbtrAgt> <PmtInf>
<FinInstnId> … 2nd transaction …
<BIC>WOWIDES1</BIC> </PmtInf>
</CstmrCdtTrfInitn> </Document>
</FinInstnId>
</DbtrAgt>

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 8


Security Layer
Example: Payload Security with PKCS#7 / CMS

Public-Key Cryptography Standard #7


Cryptographic Message Syntax (= successor to PKCS#7)
Mature Public Standard: IETF RFC 2315 / 5652 – Used by S/MIME
(PKCS#7 http://tools.ietf.org/html/rfc2315 / CMS http://tools.ietf.org/html/rfc5652)

PKCS#7 is available in SAP ECC system from early releases on


(http://help.sap.com/saphelp_nw73/helpdata/en/5c/f311370ceae904e10000009b38f936/frameset.htm )

PKCS#7 allows a variety of content types inside the message:


▪ Signed data
▪ Enveloped (=encrypted) data
▪ One step SignedAndEnveloped data or sequence of signed and enveloped data
SAP Multi-Bank Connectivity can send and receive payload as PKCS#7
Message (signed and encrypted content, certificates inside)
Additional security layer above TLS or SSH
Signature can be used for debit account authorization check

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 9


Security Layer
Payload Security Alternatives

As alternative to the standard payload security via PKCS#7, SAP Multi-


Bank Connectivity also supports PGP and XML Digital Signature

▪ Pretty Good Privacy (PGP)


–Based on OpenPGP standard
(http://tools.ietf.org/html/rfc4880)
–Signature + encryption

▪ XML Digital Signature


–Based on W3C standard “XML Signature Syntax and Processing”
(http://www.w3.org/TR/xmldsig-core1/)
–Only signature / no encryption

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 10


Message Layer
SAP Multi-Bank Connectivity Message Generic Transport Format
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!-- Request Message --> SOAP Message
<SOAP:Envelope ▪ Messages are transported as SOAP documents
xmlns:SOAP=http://schemas.xmlsoap.org/soap/envelope/ ▪ But: Messages can be sent/received also using native
xmlns:SAP="http://sap.com/xi/XI/Message/30"> application payloads (e.g. pain.001) without Message
<SOAP:Header /> wrapping
<SOAP:Body> MessageBulk
▪ SOAP Body contains a message bulk with multiple
<n0:FSNMessageBulk xmlns:n0="http://sapcd.com/fsnagt">
messages inside
<FSNMessage> Message Header
<SenderId>DE49900100000001000023</SenderId> ▪ Sender/ReceiverID
<ReceiverId>WOWIDES1</ReceiverId> ▪ Used for routing
<MessageType>pain.001.003.03</MessageType>
▪ IDs agreed between bank and corporate
<FileName>DTA120807181425_0000</FileName>
▪ Bank-ID is unique in context of SAP Multi-Bank
<NumberOfRecords>17</NumberOfRecords>
<MessageId>MID-SAP-SCT-812001</MessageId> Connectivity. Corporate-ID is unique in context of
<RelatedMessageId>ABC-123</RelatedMessageId> a bank
<ExtendedHeader > <!-- … --> </ExtendedHeader> ▪ Payload information
▪ MessageID is a sender unique ID
<MessageContent> ▪ Number of records: Validation and billing
QlNOX2lzX3N1cGVyIQ== ▪ RelatedMessageID refers to previous messages in case
</MessageContent> of correlated messages (e.g. pain.001 / pain.002)
</FSNMessage> ▪ ExtendedHeader allows flexible extensions
Message Content
</n0:FSNMessageBulk> ▪ Message content is encrypted, signed and base64
encoded
</SOAP:Body> ▪ Send/receive native application payloads without
</SOAP:Envelope> security envelopes
© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 11
Session Layer
File Exchange option: Usage of SFTP with SSH

SSH as basic session protocol


▪ On top of Internet and TCP/IP (port 22 for SSH)
▪ leveraging Internet infrastructure almost everywhere available (e.g. firewall,
proxy)
▪ Transport level security: Using SSH for encryption and client/server
authentication
(specification see client: http://tools.ietf.org/html/rfc4252; server: http://tools.ietf.org/html/rfc4253
chapter 7)

SFTP on top of SSH


▪ Adds file exchange commands (get, put, ls etc.)
(specification: http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02)
▪ To agree on:
▪ sftp login und key relation (per System vs. per System-Corporate (tenant))
▪ Directory structure
▪ Filename conventions
▪ File status and server actions (e.g. what happens after successful ‘get’)

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 12


Session Layer
Webservice option: Usage of HTTPS with XI protocol

HTTPS as basic session protocol


▪ On top of Internet and TCP/IP (port 443 for TLS)
▪ leveraging Internet infrastructure almost everywhere available (e.g. firewall,
proxy)
▪ Transport level security: Using TLS for encryption and client/server
authentication
(specification see http://tools.ietf.org/html/rfc5246 )

XI 3.0 message protocol on-top


▪ Adds reliable message transfer
▪ Message will be stored until it is successfully delivered

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 13


Session Layer
AS2 option

HTTPS as basic session protocol


▪ as described before
▪ Transport level security: Using TLS for encryption and client/server
authentication
(specification see http://tools.ietf.org/html/rfc5246 )

AS2 (Applicability Statement 2) transfer protocol on-top


▪ Standard specified in http://tools.ietf.org/html/rfc4130
▪ Adds reliable file transfer based on HTTP and MIME standards
▪ Message will be stored until it is successfully delivered
▪ Makes use of S/MIME for providing message level security signatures and
encryption

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 14


Transport and Network Layer

Transport and network layer use TCP/IP and Internet


Internet
▪ Usage of the public Internet connectivity
▪ Point-to-point connections not supported

TCP/IP
▪ TCP and IPv4/IPv6 as usual in the Internet

Optional: VPN
▪ VPN via IPSec is supported on request

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 15


Solution Components
SAP Cloud Platform Integration used by
SAP Multi-Bank Connectivity

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 17


SAP Multi-Bank Connectivity Connector

▪ Provided for corporates using SAP ERP systems


▪ ABAP Add-On to SAP ECC to simplify integration with
SAP Multi-Bank Connectivity
▪ Already included in S/4HANA
▪ Handles:
–Wrapping of SAP Multi-Bank Connectivity Messages
–Connectivity to SAP Multi-Bank Connectivity (via XI
3.0 protocol)
–Security (PKCS#7)
–Optional: Generate Tamper
Protection signatures
▪ Local monitoring of sent/received
messages

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 18


SFTP Connectivity

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 19


System Landscape

Separated Landscapes
▪ Trial – for demos and
trials
▪ Test – connected to
customer test systems +
simulators
▪ Prod – productive
communication with other
participants
–separated db schemas, key
stores, users, …
© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 20
Message Flows
Communication Pattern: Push vs. Pull

Push Pull

Push is: Pull is:


• Asynchronous one-way request • Synchronous request/response
• Lower latency • Has select query, might return n messages
• Retry in case if receiver unavailability • Higher latency due to polling period
• Quality of service: at-least-once per message • Needs a pull trigger at receiver
• Quality of service: at-least-once per message

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 22


Communication Pattern Combinations

Supports push and pull patterns


Participant can select a combination for both messaging directions:
Push-push
▪ Participant pushes messages to SAP Multi-Bank Connectivity / SAP Multi-Bank
Connectivity pushes messages to participant
–bi-directional communication with low latency ✓
–requires participant to open his firewall for inbound calls from external sources 
Push-pull
▪ Participant pushes messages to SAP Multi-Bank Connectivity / Participant pulls
messages from SAP Multi-Bank Connectivity
 communication is always triggered by participant
 no need to open the firewall on participant side for inbound calls ✓
 higher latency in one direction 

▪ (The other combinations pull-push and pull-pull are also possible, but don’t provide
any additional benefit.)

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 23


Security - Isolation, Encryption
Isolation

Separate Tenants
▪ Every participant has an own tenant
–Separate user/role management
–Separate handling of key material
–Separate integration flows

Isolated Worker Nodes


▪ The worker nodes for each tenant run in separate VMs
▪ VMs are “sandboxed” by the platform so that they can’t influence other VMs
–VMs are only visible via the load balancer

Isolated DB schemas
▪ The data for each tenant is stored in separate database schemas
▪ Every tenant is using own keys for database encryption

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 25


Data Protection by Encryption on Multiple Levels

Data is encrypted in-transfer


–Point-to-point Transport Level Security (TLS/SSH)
–Message Level Security (PKCS#7, PGP)
–optional VPN
… and at-rest
–DB Encryption (AES 128)
 Message Level Security (PKCS#7, PGP) on SFTP server

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 26


Optional
Tamper Protection Feature
Problem Statement

Current situation w/o SAP Multi-


Bank Connectivity
▪ Direct communication corporate –
bank
Bank can rely on signature from
corporate

Situation with SAP Multi-Bank


Connectivity as intermediary
▪ Mapping in SAP Multi-Bank
Connectivity invalidates original
signature
▪ Only peer-to-peer trust
Bank can’t directly rely on the
corporate signature any more

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 27


Optional
Tamper Protection Feature
Solution

SAP Multi-Bank Connectivity


Tamper Protection Concept
–The Connector on corporate side
can be configured to extract the
invariant data of a payment and sign
it with the corporate keys (1+2)
–This signature stays untouched (3)
–The bank can verify the corporate
signature and compare the invariant
data with the received payment
document. (4+5)
 Verification that content of payment
was not changed

▪ Optional feature
–Corporate side implementation for standard ISO 20022 messages is part of SAP
Multi-Bank Connectivity Connector
–Sample implementation for bank side verification available in Java
© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 28
Key Management
Overview of Keys and Certificates

Corporate SAP Multi-Bank Connectivity Bank

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 30


Setting up Keys without SAP Multi-Bank Connectivity

2. Sender sends certificate signing


Certificate Authority
request (including the public key) to (CA)
Certificate Authority.

3. Certificate Authority signs


public key and returns signed
certificate back to Sender

5. Sender shares certificate


Sender e.g. (including the public key of
Sender) with Receiver
Receiver e.g.
Corporate Bank

6. Receiver can verify the CA


1. Sender generates a key pair
signature of certificate and
stores certificate
4. Sender stores certificate

 and vice-versa 
(receiver will also generate own
key and share certificate)

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 31


Transmitting files using keys without
SAP Multi-Bank Connectivity

3. Sender sends signed&encrypted


file to receiver
Sender e.g. Receiver e.g.
Corporate Bank

1. Sender signs file using 3. Receiver decrypts received


Sender private key files using Receiver private key
4. Receiver verifies signature of
2. Sender encrypts file using files using Sender public key
Receiver public key

The reverse communication


(bank to corporate) works
analogously - with switched roles

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 32


Setting up keys with SAP Multi-Bank Connectivity

2. Sender sends certificate signing


Certificate Authority
request (including the public key) to (CA)
Certificate Authority.

3. Certificate Authority signs


public key and returns signed
certificate back to Sender

5. Sender shares
certificate with SAP 9. Receiver shares
Sender e.g. Multi-Bank certificate with SAP Receiver e.g.
Connectivity Multi-Bank Connectivity
Corporate Bank
SAP Multi-Bank
8.a SAP Multi-Bank Connectivity 8.b SAP Multi-Bank
Connectivity shares Connectivity shares
SAP Multi-Bank SAP Multi-Bank
Connectivity Connectivity
certificate with certificate with
1. Sender generates a key pair Sender 6. SAP Multi-Bank Connectivity Receiver
stores certificate
4. Sender stores certificate 7. SAP Multi-Bank Connectivity
generates key pair

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 33


Transmitting files using keys with
SAP Multi-Bank Connectivity
3. Sender sends 9. SAP Multi-Bank
signed&encrypted file Connectivity sends
to SAP Multi-Bank signed&encrypted
Connectivity file to Receiver

Sender e.g. SAP Multi-Bank Receiver e.g.


Corporate Connectivity Bank

4. SAP Multi-Bank Connectivity 10. Receiver decrypts file using


1. Sender signs file using Sender Receiver private key
private key decrypts file using SAP Multi-Bank
Connectivity private key 11. Receiver verifies signature
2. Sender encrypts file using SAP using SAP Multi-Bank
Multi-Bank Connectivity public key 5. SAP Multi-Bank Connectivity
verifies signature with Sender public Connectivity public key
key
6. SAP Multi-Bank Connectivity
Performs transformation
7. SAP Multi-Bank Connectivity signs
payload using SAP Multi-Bank
Connectivity private key
8. SAP Multi-Bank Connectivity
encrypts file using Receiver public key

The reverse communication (bank to corporate) works analogously - with switched roles

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 34


High Availability and Disaster
Recovery
High Availability

Application
▪ Two running worker nodes – if first node fails, second node can take over

Infrastructure
▪ Messaging Service – running with 2 brokers in master/slave mode

Database
▪ Running on Sybase ASE Cluster Edition
▪ Redundant storage hardware (Netapp Filers)

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 36


Disaster Recovery Overview

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 37


Disaster Recovery Details

Setup
–Secondary data center incl. all network infrastructure (hot site) for SAP Multi-Bank
Connectivity in a different region
–SAP Hana Cloud Platform in hot-standby (providing VMs and central services)
▫ Continuous data base replication via secured communication channel.
–SAP Multi-Bank Connectivity SFTP server in warm-standby (synchronized files, but
server not started)
▫ Continuous file replication via secured communication channel.
–SAP Multi-Bank Connectivity applications in warm-standby (deployed, but VMs not
started)
–Global traffic management (GTM) switches all requests to secondary site after a
disaster

Recovery Point Objective (RPO): 30 min


▪ maximum 30 minutes data loss

Recovery Time Objective (RTO): 2 hrs


▪ maximum 2 hours for restoration of service
© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 38
Disaster Recovery Sites

Current Setup
▪ Primary data center in St.Leon-Rot, Germany
▪ Secondary data center in Ashburn, USA
–(Secondary data center for global SAP Identity Service is Newton Square, USA)

Planned Setup
▪ Have both sites in the same legal area in order to comply with EU data protection
regulations
▪ EU:
–Primary site: St.Leon-Rot
–Secondary site: Amsterdam
▪ US:
–Primary site: Ashburn
–Secondary site: Phoenix

© 2018 SAP SE or an SAP affiliate company. All rights reserved. ǀ PUBLIC 39


Appendix

You might also like