sap financial services network – architecture

Financial Services Network

Architecture

Christian Becker – FSN Architect

2016

Customer

© 2016 SAP SE or an SAP affiliate company. All rights reserved. 2Customer

Legal Disclaimer

The information in this presentation is confidential and proprietary to SAP and may not be disclosed without the

permission of SAP. 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 document or any

related presentation, or to develop or release any functionality mentioned therein. This document, or any related

presentation 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 on this document is not a commitment, promise or legal obligation to deliver any material, code or

functionality. This document 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

document is for informational purposes and may not be incorporated into a contract. SAP assumes no

responsibility for errors or omissions in this document, and shall have no liability for damages of any kind including

without limitation direct, special, indirect, or consequential damages that may result from the use of this document.

This limitation shall not apply in cases of intent 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.

FSN Architecture LayersFSN Integration Scenario and Architecture Layers


Business Process: Settle & Pay, Reconcile

Corporate FSN

CloudBank

Bank Statement

Bank Statement

Create Intra-day

Bank Statement

Upload Bank Statement

for information Create End-of-day

Bank Statement

Bank Statement

Bank Statement

Upload legal binding

Bank Statement

Corporate FSN

CloudBank

Payment

Payment

Payment Status Report

Process Payment

(Backend)

Continue Payment

Processing

(Backend)


Update BCM Status

(e.g. Received by Bank)

Update BCM Status

(e.g. Accepted by Bank)

Payment Run


1 2


System Overview

Technical Communication:

• Various connectivity options (e.g. https, sftp)

• High security (multiple security layers)

• Reliable messaging: “at-least-once” quality

• Bidirectional with multiple communication patterns

(e.g. push-push, push-pull)

• Integration capabilities e.g.:

• Routing

• Mapping

• Security Protocol Mediation

Infrastructure:

• Based on SAP HANA Cloud Platform

• Virtualization and scalability

• Trial, test and production systems

• Multi-tenancy with strict isolation

• Multiple services, e.g. Persistency, Identity

Management, Key Management

• (Java) application development on-top


Protocol Layers(roughly based on OSI layers)

Protocol Layer Used technology Remarks

6. Application Predefined set of industry

standard message formats1

Internally FSN maps and

normalizes to FSN Canonical

Data Model

5. Security PKCS#7 -or- PGP -or-

XML Digitial Signature

Certificates exchanged during

onboarding

4. Message FSN message format FSN 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)

Technolo

gy

……

……

……

A

pplic

ation

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

2 = available in pull scenario for corporates; in discussion for banks


Application LayerExample: 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

http://www.iso20022.org/


Application LayerExample: ISO 20022 pain.001 Payment with two Transactions

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03

sap_pain.001.001.03.xsd">

<CstmrCdtTrfInitn>

<GrpHdr>

<MsgId>MID-SAP-EBA-SCT-812-001</MsgId>

<CreDtTm>2009-10-27T08:30:47Z</CreDtTm>

<NbOfTxs>2</NbOfTxs>

<InitgPty>

<Nm>Deutsche Wunschbank AG</Nm>

</InitgPty>

</GrpHdr>

<PmtInf>

<PmtInfId>PID-SAP-EBA-SCT-812-001-A</PmtInfId>

<PmtMtd>TRF</PmtMtd>

<ReqdExctnDt>2009-11-26</ReqdExctnDt>

<Dbtr>

<Nm>Max Mustermann</Nm>

</Dbtr>

<DbtrAcct>

<Id>

<IBAN>DE49900100000001000023</IBAN>

</Id>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BIC>WOWIDES1</BIC>

</FinInstnId>

</DbtrAgt>

(continued) <CdtTrfTxInf>

<PmtId>

<EndToEndId>

E2EID-SAP-EBA-SCT-812-001-A1

</EndToEndId>

</PmtId>

<Amt>

<InstdAmt Ccy="EUR">5.10</InstdAmt>

</Amt>

<CdtrAgt>

<FinInstnId>

<BIC>DRESDEFFXXX</BIC>

</FinInstnId>

</CdtrAgt>

<Cdtr>

<Nm>DEGUDENT GMBH</Nm>

</Cdtr>

<CdtrAcct>

<Id>

<IBAN>DE27500800000090521500</IBAN>

</Id>

</CdtrAcct>

<RmtInf>

<Ustrd>VZW unstrukturiert

SAP-EBA-SCT-812-001-A1</Ustrd>

</RmtInf>

</CdtTrfTxInf>

</PmtInf>

<PmtInf>

… 2nd transaction …

</PmtInf>

</CstmrCdtTrfInitn> </Document>


Security LayerExample: 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

FSN 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

http://tools.ietf.org/html/rfc2315


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


Security LayerPayload Security Alternatives

As alternative to the standard payload security via PKCS#7, FSN 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


http://www.w3.org/TR/xmldsig-core1/

Message LayerFSN Message Generic Transport Format

<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>



<SOAP:Envelope

xmlns:SOAP=http://schemas.xmlsoap.org/soap/envelope/

xmlns:SAP="http://sap.com/xi/XI/Message/30">

<SOAP:Header />

<SOAP:Body>

<n0:FSNMessageBulk xmlns:n0="http://sapcd.com/fsnagt">

<FSNMessage>

<SenderId>DE49900100000001000023</SenderId>

<ReceiverId>WOWIDES1</ReceiverId>

<MessageType>pain.001.003.03</MessageType>

<FileName>DTA120807181425_0000</FileName>

<NumberOfRecords>17</NumberOfRecords>

<MessageId>MID-SAP-EBA-SCT-812-001</MessageId>

<RelatedMessageId>ABC-123 </RelatedMessageId>

<ExtendedHeader >  </ExtendedHeader>

<MessageContent>

QlNOX2lzX3N1cGVyIQ==

</MessageContent>

</FSNMessage>

</n0:FSNMessageBulk>

</SOAP:Body>

</SOAP:Envelope>

FSNMessage Header Sender/ReceiverID

Used for routing IDs agreed between bank and corporate Bank-ID is unique in context of FSN. Corporate-ID

is unique in context of a bank Payload informationMessageID is a sender unique ID Number of records: Validation and billing RelatedMessageID refers to previous messages in case

of correlated messages (e.g. pain.001 / pain.002) ExtendedHeader allows flexible extensions

FSNMessage ContentMessage content is encrypted, signed and base64

encoded FSN can send/receive also native application payloads

without security envelopes

FSNMessageBulk SOAP Body contains a FSN message bulk with multiple

FSN messages inside

SOAP Message FSN messages are transported as SOAP documents But: FSN can send/receive also native application

payloads (e.g. pain.001) without FSN Message wrapping


Session LayerFile 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 FSN System vs. per FSN-System-Corporate (tenant))

Directory structure

Filename conventions

File status and server actions (e.g. what happens after successful ‘get’)



http://tools.ietf.org/html/draft-ietf-secsh-filexfer-02


Session LayerWebservice 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



Session LayerAS2 option (new)

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




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

FSN ComponentsLandscape View, Technical Components


HANA Cloud Integration used by FSN


FSN Connector

FSN Connector

Provided for corporates using SAP ERP systems

ABAP Add-On to simplify integration with FSN

Already included in S4/HANA

Handles:

Wrapping of FSN Messages

Connectivity to FSN (via XI 3.0 protocol)

Security (PKCS#7)

Optional: Generate Tamper

Protection signatures

Local monitoring of sent/received

messages


SFTP Connectivity


FSN System Landscape

Separated Landscapes

Trial – for demos and trials

Test – connected to customer test

systems + simulators

Prod – productive communication

with other FSN participants

separated db schemas, key

stores, users, …

FSN Message FlowsSequence View


Communication Pattern: Push vs. Pull

PullPush

Pull is:

• Synchronous request/response

• Has select query, might return n messages

• Higher latency due to polling period

• Needs a pull trigger at receiver

• Quality of service: at-least-once per message

Push is:

• Asynchronous one-way request

• Lower latency

• Retry in case if receiver unavailability

• Quality of service: at-least-once per message


Communication Pattern Combinations

FSN supports push and pull patterns

FSN participant can select a combination for both messaging directions:

Push-push

Participant pushes messages to FSN / FSN pushes messages to participant

bi-directional communication with low latency

requires participant to open his firewall for inbound calls from FSN

Push-pull

Participant pushes messages to FSN / Participant pulls messages from FSN

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.)

Content and Mapping


Mapping Approach

Instead of point-to-point mappings…

Each FSN tenant maps to a canonical

message format

Reduces N:M mapping effort

Common format for value applications

e.g. FSN Business Cockpit

Sender Tenant Receiver Tenant


FSN Standard Message Formats vs Custom Formats

FSN standard message formats

Recommended formats

Include rules for clean interoperability with other FSN participants

Can be used out-of-the box

Message Implementation Guides (MIGs) exist

Mapping Guides (MAGs) and base map implementations exist

Standard content (DMEE tree) available for corporates with SAP ERP systems

allow quick onboarding

Custom formats / modifications of FSN standard messages

Are also possible, but require a custom project

Definition of custom MIG

Definition of MAG (custom format <-> FSN canonical format)

Mapping implementation/adoption of base maps

takes more time during onboarding; potentially higher cost for custom dev


FSN Standard Message Formats

Available standard FSN message formats

ISO 20022 (March 2009 release)

pain.001.001.03, pain.002.001.03, pain.008.001.02, camt.052.001.02, camt.053.001.02,

camt.054.001.02

CGI / SEPA variants of the above ISO 20022 messages

Upcoming additional standards

Swift MT940

BAI2

IDOC (PEXR)

FSN Canonical Message Format

Used internally for mapping and applications

Based on ISO20022 (April 2012 release)

FSN SecurityIsolation, Encryption


Isolation

Separate Tenants

Every FSN participant has an own tenant in the HANA Cloud Platform

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


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


Tamper ProtectionProblem Statement

Current situation w/o FSN

Direct communication corporate –

bank

Bank can rely on signature from

corporate

Situation with FSN as intermediary

Mapping in FSN invalidates original

signature

Only peer-to-peer trust

Bank can’t directly rely on the

corporate signature any more

Optional Feature

on top of FSN


Tamper ProtectionSolution

FSN Tamper Protection Concept

The FSN 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 FSN Connector

Sample implementation for bank side verification available in Java

Optional Feature

on top of FSN

Key managementKey storage, key exchange


Overview of Keys and Certificates

Corporate FSN on SAP Cloud Bank


Setting up Keys without FSN

Sender e.g.

Corporate

Receiver e.g.

Bank

Certificate Authority

(CA)2. Sender sends certificate signing

request (including the public key) to

Certificate Authority.

3. Certificate Authority signs

public key and returns signed

certificate back to Sender

5. Sender shares certificate

(including the public key of

Sender) with Receiver

6. Receiver can verify the CA

signature of certificate and

stores certificate4. Sender stores certificate

1. Sender generates a key pair

and vice-versa

(receiver will also generate own

key and share certificate)


Transmitting files using keys without FSN

Sender e.g.

Corporate

Receiver e.g.

Bank

3. Receiver decrypts received

files using Receiver private key

4. Receiver verifies signature of

files using Sender public key

1. Sender signs file using

Sender private key

2. Sender encrypts file using

Receiver public key

3. Sender sends signed&encrypted

file to receiver

The reverse communication

(bank to corporate) works

analogously - with switched roles


FSN

Setting up keys with FSN

Sender e.g.

Corporate

Receiver e.g.

Bank

4. Sender stores certificate

5. Sender shares

certificate with FSN

8.a FSN shares FSN

certificate with

Sender

6. FSN stores certificate

7. FSN generates FSN key pair

Certificate Authority

(CA)2. Sender sends certificate signing

request (including the public key) to

Certificate Authority.

3. Certificate Authority signs

public key and returns signed

certificate back to Sender

9. Receiver shares

certificate with FSN

1. Sender generates a key pair

8.b FSN shares FSN

certificate with

Receiver


Transmitting files using keys with FSN

10. Receiver decrypts file using

Receiver private key

11. Receiver verifies signature

using FSN public key

1. Sender signs file using Sender

private key

2. Sender encrypts file using FSN

public key

4. FSN decrypts file using FSN private

key

5. FSN verifies signature with Sender

public key

6. FSN Performs transformation

7. FSN signs payload using FSN

private key

8. FSN encrypts file using Receiver

public key

3. Sender sends

signed&encrypted file

to FSN

9. FSN sends

signed&encrypted

file to Receiver

FSNSender e.g.

Corporate

Receiver e.g.

Bank

The reverse communication

(bank to corporate) works

analogously - with switched roles

FSN Business CockpitBusiness Monitoring


Adding FSN Business Cockpit

Optional HANA based web application for business monitoring & approval of

payments

In addition to Integration Flows

Currently only for corporates

Optional Feature

for Corporates


Business Cockpit – Monitoring Flow

Copies of all messages moving through corporate tenant are forwarded to Business Cockpit

Additional storage & analysis based on HANA

Correlation of corporate messages and bank status responses to provide business

monitoring


Business Cockpit – Approval Flow

Flow from corporate to bank interrupted

Messages first flow to Business Cockpit

Business User can approve or reject messages

– Approved messages are forwarded to bank

– Rejected messages are stopped

?

User Approval

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)


Disaster Recovery Overview


Disaster Recovery Details

Setup

Secondary data center incl. all network infrastructure (hot site) for SAP FSN 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 FSN SFTP server in warm-standby (synchronized files, but server not started)

– Continuous file replication via secured communication channel.

SAP FSN 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


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

sap financial services network – architecture

Technology