Interface Guide Part 0 General Rules and Principles_R2
Contents
1. R LINK M 20 C RELA reference of the message that is confirmed 4l1c 16x 16 S LINK This line indicates the start of a logical SWIFT block Sequence A1 Linkages is the name of the block This line is not part of the SWIFT format and is for informative layout purposes fe Sequence A1 Linkages A block is in most case delimited with a 16R 16S Tag The LINK qualifier indicates that this block is Sequence A1 Linkages i 16 R LINK a LL RNM GENERIC RULES AND PRINCIPLES PAGE 7 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles l 16 S LINK When several options are possible for a certain tag M 95 P PSET Place of settlement BIC code 4 c 4 a2 a2 c 3 c R PSET Place of settlement proprietary code 4 c 8c 34x Q PSET Place of settlement name and address 4 c 4 35x The format of the lines borders indicates what field information should be read together In this case the P R and Q are options If on the same line of R in another column a value is put this means that that value belongs to that specific option e g P R and Q will have it s own format although only 1 option is used for the 95a PSET tag Typographic styles are used only for readability no interpretation should be attached to the use of this Next types can be found in the sheets e bold when the tag is mandatory e bold cursive2. when the tag is conditional mandatory 2 1 3 SWIFT FORMAT The format of a field is defined as follows nn Maximum length nn Fixed length nn nn Minimum and maximum length nn nn Maximum number of lines times maximum line length Brackets indicate an optional element The allowed characters are defined as follows n Digits d Digits with decimal comma h Uppercase hexadecimal a Uppercase letters c Uppercase alphanumeric e Space x SWIFT character set X S W I F T Character Gei Code Alphabetical Characters A to Z upper case EBCDIC a to z lower case EBCDIC Numeric Characters 0to9 EBCDIC Special Characters 2 SPACE CrLf EBCDIC e Uppercase level A ISO 9735 characters Y S W LF T Character Set Code Alphabetical Characters A to Z upper case EBCDIC Numeric Characters 0to9 EBCDIC Special Characters SPACE EBCDIC D KA RM GENERIC RULES AND PRINCIPLES PAGE 8 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Special Characters incompatible with international telex AR lt gt EBCDIC e z SWIFT extended character set Alphabetical Characters A to Z upper case EBCDIC a to z lower case EBCDIC Numeric Characters 0to9 EBCDIC Special Characters Crlf EBCDIC SPACE For details see the SWIFT documentation Mes
3. Mandatory by SWIFT Authorisation Context Authenticator M Requestor Request Control M Request Header M Payload O Application Header but mandatory for _Document CCBM2 Cryptographic Blocks O Message Signature O 4 2 1 1 Authorisation Context Authenticator Requestor This block contains the User Distinguished Name DN of the entity that authorised the sending of the message The User DN is a X 500 distinguished name ending with o lt BIC8 gt o swift It is used by SWIFT to identify and authenticate the sending user The sending user can be an operator or an application certificate Example BANKNL2A sends a XML request to CCBM2 using the following User DN lt SwSec UserDN gt cn jweersma o banknl2a o swift lt SwSec UserDN gt cce GENERIC RULES AND PRINCIPLES PAGE 19 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Usage Usage Requestor DN Responder DN 4 2 1 2 Request Control This block indicates vis a vis SWIFT whether the request Contains cryptographic operations to be performed Requires non repudiation of emission NRE Is to be handled by means of Store and Forward In CCBM2 all messages having writing access require NRE For these messages the field lt NRIndication gt must contain the value TRUE 4 2 1 3 Request Header This block contains the following information Distinguished Name of the Requestor Reques
4. gt lt From gt Business lt To gt Identifies the Will have to be application to lt Type gt receiving filled by the which the 2222 application for sender of the document is lt Type gt which the XML message sent lt Id gt document is 2222 created lt Id gt lt To gt Message lt MsgRef gt The unique Reference identifier of the message Creation Date lt CrDate gt Date and time at which the message was created N B The Application Header only contains the From or the To element depending if the message is sent or received by CCBM2 D KA RNM GENERIC RULES AND PRINCIPLES PAGE 22 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Usage Usage 4 2 2 Security Security Aspects 4 2 1 5 Cryptographic Blocks This block is general optional but mandatory when NRE is applied There are no specific rules defined for this block by CCBM2 4 2 1 6 Message Signature This block is not relevant for CCBM2 It might be used according to the rules defined by SWIFT The following security aspects are of importance O Authenticity The common SWIFT functionality using the PKI solution for establishing the authenticity of a sender of a SWIFT message is used It is not clear yet if RBAC will be used by CCBM2 and if yes if a special A2A role will be defined for CCBM2 Non repudiation The common SWIFT functionality for the non repudiation of a sent or received message is
5. Gi EUROPEAN CENTRAL BANK EUROSYSTEM CCBM2 Interface Guide Part O Generic Rules and Principles CCRM 2 March 2011 Working Version Public CCBM2 Interface Guide Part 0 Generic Rules and Principles TABLE OF CONTENTS 1 SCOPE OVERVIEW ugebeee reegen EE ETA EE 3 1 1 SCOPE OF THIS REKLEASGSE eebe seccsceteeeneveedcewccnte sauaina aaaea eaaa adiasa aaaeaii 3 We E uge UC COM EE 5 2 MESSAGE TEMPLATE CONVENTIONS woessecesesexcsssccnsiencenexcevesntanenssxereensensnannsnnensenenanseuenne 7 2 1 Reading SWIFT FIN format descriptions IGO15022 csccssseeesseeeeeseeeeseeeeneeeeeeeeeeseeaeenseeenseees 7 2A Ne GOWNS A A O AAE EA A A EE N TA E 7 E E e VT 7 2 13 SWIFT TOMAR TEE 8 2 2 Reading the XML format AeSCriptiOns c cseccsseeeeenee essen eeseeeeneeeeeeeeseseaeseseeeeeeeeeseeeseseaeeeeeeeeeeas 10 3 AZA COMMUNICATION CHANNELS AND STANDARDS USED BY CCBMM2 11 4 TECHNICAL SPECIFICATIONS PER NETWORK ccccccessseeeeeeeeeeeeeeeeeeeeneneeeeeeeeeeeeeeeees 14 4 1 SWIFT Net FIN Messages eege Ee EENS EENEE ie teecadedecedevsaderscedeeret cated 14 4 1 1 Headers Trailers and double entry check 14 4 1 2 SOCUIMY TE 18 4 2 SWIFTNet InterAct FileAct MeSSaQeS csseceeeeeeseteeeseeeeneeeeeeeeeeseaeseneeeenseeeseeseseaesnseeeeeeeeneeaes 19 4 2 1 Global Structure of a XML Message e sesesiessiessresrissrississriisstissrinttisttnnttnnntnnntnnntnnnntne nt 19 A 22 SO CUIMY ET 23 En
6. KA d NV TABLE OF CONTENTS PAGE 2 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 1 SCOPE OVERVIEW The Interface Guide is part of the CCBM2 functional documentation shared across five documents The Business Requirements Document BRD The Detailed System Requirements DSR The Human Interface Design HID The User Manual UM The Interface Guide IG OO ON E CO The Interface Guide provides the specifications of the messages and files to be exchanged with CCBM2 therefore this document is only related to the Application to Application Mode A2A The BRD and DSR provide the requirements of the CCBM2 system The BRD contains high level requirements and the DSR detailed requirements These requirements serve as basic information to the functional design of CCBM2 system processes The HID describes the GUI Graphical User Interface of CCBM2 user screens and is used later on for translating logical test cases into physical test cases The UM describes how the CCBM2 system can be used so a description of the available screens and how to use them The User Manual and Human Interface Design are therefore related to the User to Application Mode U2A 1 1 SCOPE OF THIS RELEASE The current version of the Interface Guide is work in progress Its content envolves with the analysis provided during each release of other functional documents Therefore it is not intended to be a complete and updated document in ad
7. OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 1 2 INTRODUCTION The Interface Guide consists of five parts IG Part IV ESCB IG Part Counterpart Part O CCBM2 Generic Rules and Principles IG Part III NCB CMS o Part0 provides the generic rules and principles o an overview of the validation rules applicable to the various incoming messages o an overview of the enrichment rules applicable to the different outgoing messages o the overall contextual information as well as o conventions being applicable to the 3 other parts of the Interface Guide Generic rules and principles are always bundled with any other part of the Interface Guide Scope Limitation Useful content for DSR Release1 and Release2 only and still subject to amendments Network Specifications not to be considered as completed and updated Validation Rules are subject to amendments during subsequent releases More detail on rules will be given in next release of Interface Guide cce GENERIC RULES AND PRINCIPLES PAGE 5 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles O Part I describes the messages and files to be exchanged between CCBM2 and Counterparties CP or its authorised sender delegated actor This document will represent the Counterparties message specifications based on a first version of the CCBM2 Harmonized CP format This is one of the two Public parts o
8. Use in CCBM2 M Block 1 Identifier M Application F F FIN Identifier M Service 01 Identifier M LT Address 4la2la2 ici c3 c BIC LT 12 digits Message from participant to CCBM2 o Sender s LT address Message from CCBM2 to participant o Receivers LT address M Session Aln Number M Sequence 6 n Number D KA RNM GENERIC RULES AND PRINCIPLES PAGE 14 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Usage Structure when sending a Message Message 4 1 1 2 Application Header The Application Header is used in every message type sent to or received from CCBM2 via SWIFTNet FIN It has different formats depending on whether the participant sends or receives a message The Application Header has the following structure when a participant sends a message via SWIFTNet FIN to CCBM2 Application Header Status Field Name Format Use in CCBM2 M Block 2 Identifier M Input Output l Input for SWIFT Identifier M Message 3 n Examples of Message Type Types used in CCBM2 are 540 541 542 202 204 etc M Destination A4la2la2 ci c3 c BIC LT 12 digits Address o Receivers LT address M Message Nor U Not relevant in CCBM2 Priority O Delivery 1 n Monitoring O Obsolescence 3 n e Period Structure when The Application Header has the following structure when a participant receiving a receives a message via SWIFTNet FIN f
9. f the Interface Guide Part Il describes the messages and files to be exchanged between CCBM2 and CSDs in the various participating countries This is the second of the two Public parts of the Interface Guide Scope Limitation Autocollaterisation and Triparty services related messages are out of the scope of this release The described communication is currently limited to the usage of SWIFTNet FIN service This document will represent the CSD message specifications based on the information received from NCBs to date Part Ill describes the messages and files to be exchanged between CCBM2 and NCB s This is the ESCB Internal part of the Interface Guide Part IV describes the communication between ESCB applications and CCBM2 f e tender applications for importing allotment results accounting systems etc as well as communication between CCBM2 and Dataproviders Target2 PHA Target2 Securites T2S This is the ESCB Internal part of the Interface Guide 1 Note The work on the harmonization of the messages towards counterparties has not been yet completed hence this part will not be published in this release D KA eM GENERIC RULES AND PRINCIPLES PAGE 6 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 2 MESSAGE TEMPLATE CONVENTIONS 2 1 READING SWIFT FIN FORMAT DESCRIPTIONS ISO15022 2 1 1 COLUMNS The template uses the following layout SOURCE SWIFT Format TARGET CSD S
10. ilisation Request via Secure Internet or via the User to Application Mode 2 ESCB internal network NCB2NCB communication only 3 E g Triparty collateral management service providers cce GENERIC RULES AND PRINCIPLES PAGE 11 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles MT and MX CCBM2 will support the 15015022 or so called MT messages from start on and the ISO20022 or so called MX messages standard could be supported as of Go live T2S Standards to SWIFT Corenet Internet be used per A2A A2A A2A Channel and CSD MT MX External Party MX4 Files XML Files XML Counterparty MT MX MX Files XML Files XML Third Party MT MX Custodian MX Files XML Files XML External CMS MT MX MX Files XML Files XML CCP MT MX MX Files XML Files XML Target2 PHA MT MX T2S Diagram 4 Mx messages over the SWIFT network will be supported as of Go live T2S b E MX eg Files XML The information of both tables above is depicted in the diagram below cce GENERIC RULES AND PRINCIPLES PAGE 12 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Chosen approach writing the Interface Guide Usage of SWIFT services For the development of the Interface Guide the approach is chosen to first develop the MT messages and start the discussions with the NCBs and the market on these MT
11. messages Once the discussions about the MT messages are finalised the XML format for the internet channel should be derived straight forward by using reverse engineering translation rules The reasons for choosing this approach are o The MT messages are quite commonly known o By focussing on the MT messages first changes on request by the NCBs or market participants only need to be done to the MT messages CCBM2 will make the following use of the services offered by SWIFT o For MT messages SWIFTNet FIN will be used o For A2A request response interactions SWIFTNet InterAct Store and Forward Messaging Mode will be used and FileAct Store and Forward in case of large replies from CCBM2 o For A2A request response interactions with Target2 InterAct Real time Query and Response will be used o For the delivery of files to CCBM2 containing instructions for example the non marketable assets bulkfile SWIFTNet FileAct Store and Forward will be used cce GENERIC RULES AND PRINCIPLES PAGE 13 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 4 TECHNICAL SPECIFICATIONS PER NETWORK 4 1 SWIFTNet FIN Messages 4 1 1 Headers Trailers and double entry check 4 1 1 1 Basic Header Usage The Basic Header is used in every message type sent to or received from CCBM2 via SWIFTNet FIN Structure The Basic Header has the following structure Basic Header Status Field Name Format
12. participant receives a receiving a message via SWIFTNet FIN from CCBM2 Message Trailer Status Field Name Content Use in CCBM2 Options Block 5 Identifier M Authentica MAC 8 h S tion Code M Checksum CHK 12 h TL eM GENERIC RULES AND PRINCIPLES PAGE 16 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles PDM Trailer Possible Duplicate Message Trailer PDE Trailer Possible Duplicate Emission Trailer O Training TNG Only in test and training mode O Possible PDE lt time gt lt Duplicate mir gt Emission O Possible PDM lt time gt lt Duplicate mor gt Message O Delayed DLM Message 4 1 1 4 Handling of PDM PDE Trailer A PDM trailer is added to a SWIFT message by SWIFT It is used to warn the receiver that the same message may already have been delivered by SWIFT The reason for sending a message with PDM trailer is that SWIFT does not know whether the message was already sent If CCBM2 receives a message it checks in addition to the double entry check whether the message is delivered twice once with and once without a PDM trailer o If the message without PDM trailer was already delivered then the message with PDM trailer will be ignored by CCBM2 o If the message without PDM trailer was not delivered the message with PDM trailer will be processed by CCBM2 o If the message without PDM trailer is deli
13. pecific Rules CSD Mobilisation SWIFT Tag Option Qualifier Description utilisation of field Format M O Business rule Matched Examples Instruction The first line devides the template in 2 parts Source and Target The source and target can switch place depending if it s an incomming or outgoing message The section under SWIFT format defines everything related to the SWIFT message format e SWIFT Is the field optional O conditional mandatory C M or mandatory M for SWIF Grouping tags are indicated by l 16R is used to start the block while 16S ends it Tag the SWIFT Tag Option the option of the Tag some tag have multiple options formats Qualifier the tag qualifier some Tags are used for multiple purposes Description the SWIFT usage of the field Format the format constraints imposed by SWIFT see 2 3 The section under CCBM2 CSD Specific Rules defines everything related to the field usage by the CSD CCBN2 e CSD M O is the field optional O conditional mandatory C M or mandatory M for CSD CCBM2 e Business rule a short description of how the field will be used by CCBM2 to match the CSD requirements e Matched will the field be used for matching by CSD or CCBM2 e Example an example of the tag value the Tag and Option are not used in the example The section under LIM defines the logica fields as they are used in the DSR 2 1 2 ROWS A basic introduction about the structure of a SWIFT Example 16
14. rom CCBM2 Application Header Status Field Name Format Use in CCBM2 M Block 2 Identifier M Input Output O O Output for SWIFT Identifier M Message 3 n Examples of Message Type Types used in CCBM2 are 540 541 542 598 etc M Input Time HHMM M Message 6 n4 a2 a2 c1 c3 Input date local to the cce GENERIC RULES AND PRINCIPLES PAGE 15 OF 23 CCRN Interface Guide Part 0 Generic Rules and Principles Input Ic4 n6 n sender LT address of Reference the sender session and sequence number of the sender M Date YYMMDD Output date local to the receiver M Time HHMM Output time local to the receiver M Message NorU Sender s message Priority priority 4 1 1 3 Trailer Usage The Trailer is used in every message that is exchanged with CCBM2 The content of the Trailers is different depending on whether a message is sent to or received from CCBM2 Structure when The Trailer has the following structure when a participant sends a sending a message via SWIFTNet FIN to CCBM2 Message Trailer Status Field Name Content Use in CCBM2 Options Block 5 Identifier M Authentica MAC 8 h tion Code M Checksum CHK 12 h O Training TNG Only in test and training mode O Possible PDE lt time gt lt Duplicate mir gt Emission Structure when The Trailer has the following structure when a
15. sage Format Validation Rules D KA eM GENERIC RULES AND PRINCIPLES PAGE 9 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 2 2 READING THE XML FORMAT DESCRIPTIONS The template uses the following layout ssp pm ModifyCreditLine camt 998 01 02 xsd Output message from CCBM2 CCBM2 sends SOURCE XML Format ssp pm ModifyCreditLine camt 998 001 02 xsd https target2 ecb int doc udfs IN pm library LIM reference Description utilisation of XPATH field Format M O Business rule Matched RTGS_ModifyCreditLine The first line divides the template in 2 parts Source and Target The source and target can switch place depending if it s an incomming or outgoing message The follwing columns are used e XPATH the field to map using an Xpath notation Description a short description Format the format specification details can be found in the XSD M O is the field optional O conditional mandatory C M or mandatory M Business rule a short description of how the field will be used by CCBM2 Matched will the field be used for matching by CCBM2 The section under LIM defines the logical fields as they are used in the DSR A n 9 KA RNM GENERIC RULES AND PRINCIPLES PAGE 10 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 3 A2ZA COMMUNICATION CHANNELS AND STANDARDS USED BY CCBM2 Communica tion Channels Available Channels for External Parties Choice of Channel The follo
16. thin the message then the next delivery of the same i e corrected message is not rejected because of the double entry check to allow the resending of corrected messages The following security aspects are of importance o Authenticity The common SWIFT functionality using the PKI solution for establishing the authenticity of a sender of a SWIFT message is used o Non repudiation The common SWIFT functionality for the non repudiation of a sent or received message is used o Integrity The common SWIFT functionality using the PKI solution for safeguarding the accuracy of the contents of messages and the standard SWIFT functionality to guarantee the completeness of the number of sent and received messages ACK NACK ISN OSN gap detections are used o Availibility See UDFS chapter 12 regarding the measures to guarantee the agreed availability of the CCBM2 platform o Confidentiality The common SWIFT functionality for encrypting messages using the PKl solution is used cce GENERIC RULES AND PRINCIPLES PAGE 18 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 4 2 1 Global Structure of a XML Message Global Structure of a XML Message Usage 4 2 SWIFTNet InterAct FileAct Messages A XML message via InterAct Real Time Messaging Mode and via InterAct FileAct Store and Forward Mode both in Push Mode consists of the following blocks Name of Block Optional or
17. tor DN Distinguished Name of the Responder Responder DN Service Name Request Type Priority not used by CCBM2 Request Reference The Requestor DN identifies the sending party institution that sends the XML message The Requestor DN is a X 500 distinguished name ending with o lt BIC8 gt 0 swift No registration in the SWIFTNet directory tree of the sending party or certification of this DN is required The value of the requestor field may be equal to the user DN which is used to sign the message but this is not mandatory lt Swint Requestor gt o BIC8 o swift lt Swint Requestor gt The Responder DN identifies the receiving party institution that receives the XML message The Responder DN is a X 500 distinguished name ending with o lt BIC8 gt 0 swift At this moment it is not yet known which Responder DNs will be used by CCBM2 cce GENERIC RULES AND PRINCIPLES PAGE 20 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Service Name Request Type lt Swint Responder gt o ccbmxecm o swift lt SwInt Responder gt The Service Name contains the SWIFTNet service used For CCBM2 different Service Names are in place for Customer test environment Service Name SWIFTNet Service Mode Not known yet InterAct Real time FileAct Browse Not known yet InterAct Store and Forward FileAct Live environment Service Name SWIFTNet Ser
18. used Integrity The common SWIFT functionality using the PKI solution for safeguarding the accuracy of the contents of messages and the standard SWIFT functionality to guarantee the completeness of the number of sent and received messages are used Availibility See UDFS chapter 12 regarding the measures to guarantee the agreed availability of the CCBM2 platform Confidentiality The common SWIFT functionality for encrypting messages using the PKI solution is used cce GENERIC RULES AND PRINCIPLES PAGE 23 OF 23
19. vance but in synchronisation with each release of other functional documents of CCBM2 The current version only covers the requirements for Release 1 and Release 2 of the DSR 7 DSR Releases in total all other information has been removed for readability and testability purposes For this release of the Interface Guide we consider as being out of Scope e 1S020022 so called MX messages and Internet format Reason Internet could also be used for A2A communication proprietary systems of NCBs counterparties and CSDs send messages using a CCBM2 agreed format Examples are bulk files as used for credit claims data information in the case of auto collateralisation and tri party collateral management and regular messages for collateral mobilisation The current assumption is that as far as possible for these A2A messages the ISO20022 messages will be used D KA RNM GENERIC RULES AND PRINCIPLES PAGE 3 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Part 0 Chapter 2 explains how to read the message templates Part 0 Chapter 3 and 4 have not been updated in the release and are part of this release for informative purposes only Important changes in subsequent releases of the Interface Guide will be referenced in order to keep track of modifications that influence communication system interfacing with CCBM2 and facilitate information amongst the stakeholders D KA eM GENERIC RULES AND PRINCIPLES PAGE 4
20. vered after the message with PDM trailer the message without PDM trailer will be ignored by CCBM2 A PDE trailer is added by the sender of a SWIFT message It is used to warn the receiver that the same message may already have been received The reason for sending a message with PDE trailer is that the sender is not sure whether the message was already sent If CCBM2 receives a message it checks in addition to the double entry check whether the message is delivered twice once with and once without a PDE trailer o If the message without PDE trailer was already delivered then the message with PDE trailer will be ignored by CCBM2 o If the message without PDE trailer was not delivered the message with PDE trailer will be processed by CCBM2 o If the message without PDE trailer is delivered after the message with PDE trailer the message without PDE trailer will be ignored by CCBM2 cce GENERIC RULES AND PRINCIPLES PAGE 17 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles Double Entry Check 4 1 2 SECURITY Security Aspects 4 1 1 5 Double Entry Check CCBWM2 carries out a check on the double receipt of messages If the following information regarding a SWIFT message that is received by CCBMz2 is the same as in a previously received message CCBM2 will reject the message o Sender of the message o Message Type o Sender Reference Note If a message was rejected by CCBM2 because of an error wi
21. vice Mode Not known yet InterAct Real time FileAct Browse Not known yet InterAct Store and Forward FileAct The tag containing the Service Name is called lt Swint Service gt The Request Type identifies the message type of the XML message using the standard code of the message for example sese 023 001 01 for a Marketable assetsSettlementTransactionInstruction see the SWIFT documentation for all the codes The tag containing the Request Type is called lt Swint RequestType gt cce GENERIC RULES AND PRINCIPLES PAGE 21 OF 23 CCBM2 Interface Guide Part 0 Generic Rules and Principles 4 2 1 4 Payload Usage This block contains the Application Header and the so called Document in fact the actual MX message Application The Application Header contains information that is relevant to the Header business applications that route and process the business document This information is required before opening the actual document so that the business application can process the content properly The Application Header regarding CCBM2 contains the following components Header Syntax Purpose Use in CCBM2 Element Business lt From gt Identifies the This element application from lt Type gt application that will be filled by which the 2222 has created the CCBM2 for document is lt Type gt document XML messages received lt ld gt sent by CCBM2 2222 lt Id
22. wing networks can be used by external parties to communicate with CCBM2 in A2A mode o SWIFT FIN InterAct and FileAct o Secure Internet o Corenet NCBs The technical specifications for SWIFT and Secure Internet have been given in chapter 4 Restrictions apply to which communication channel can be used depending on the actor and external proprietary systems The table below shows which channel is available for which party SWIFT Corenet Internet A2A A2A A2A CSD v v NCB when acting on behalf To be confirmed of CSD Counterparty v v Third Pary v v Custodian External CMS v v Target2 PHA v T2S To be confirmed NCB v applications For messages files sent in to CCBM2 parties can choose at each moment which of the available channels they want to use so for example for the first message of a day SWIFT can be used for the second one of the same kind of message Secure Internet etc For messages files to be received by parties from CCBM2 they have to indicate via the static data of CCBM2 for every kind of message file which channel always must be used by CCBM2 independent of the channel that was used to send in a message So for example if a Counterparty has indicated that they always want to receive a Settlement Confirmation Mobilisation Request Free of Payment via SWIFT CCBM2 will always send this message via SWIFT even if the Counterparty did send in the Mob
Download Pdf Manuals
Related Search