Implementation of Financial Message Standards to BIAN Architecture

Transcription

1 19 June 2015 Master of IT in Business Capstone Project Report BIAN-IFX-ISO20022(CARDS) Implementation of Financial Message Standards to BIAN Architecture Version 1.4 Prepared for: Prof. Alan Megargel Prepared By: Mukund Premchander, Sunil Bansal 19 th June2015 Singapore Management University Page 1 of 45

2 BAIN IFX ISO20022 (Cards) Approval Title Name Signature Date Implementation of Alan Megargel 15 th Jun 2015 Financial Message Standards to BIAN Architecture VERSION HISTORY Version Version Date Change Description Author th Apr Initial Report Mukund Premchandar, Sunil Bansal th May Mid Term Report Mukund Premchandar, Sunil Bansal th June Final Report Mukund Premchandar, Sunil Bansal th June 2015 Address Prof. Alan s review comments - Page 6 Additional updates on the Objective section - Page 9,10 Service Operations related updates - Page 24,25 Business Scenario related updates Conclusion section th June 2015 Updated reference to SMU Teaching Bank on page 43 Mukund Premchandar, Sunil Bansal Alan Megargel Singapore Management University Page 2 of 45

3 BAIN IFX ISO20022 (Cards) Table of Contents Approval... 2 VERSION HISTORY Introduction DEFINITIONS AUDIENCE REFERENCE BACKGROUND OBJECTIVE BIAN CARDS BUSINESS DOMAIN THE SERVICE DOMAIN THE BUSINESS DOMAIN BUSINESS AREA SERVICE OPERATION KEY CONCEPTS MAPPING ACTIONS TO FUNCTIONAL PATTERNS CARDS BUSINESS DOMAIN MESSAGE STANDARDS IFX ISO Mapping Procedure MAPPING TABLES FOR CARD SERVICE DOMAINS IFX MAPPING TABLE FOR CARD FACILITY IFX MAPPING TABLE FOR CARD AUTHORIZATION IFX MAPPING TABLE FOR CARD CAPTURE IFX MAPPING TABLE FOR CARD BILLING & PAYMENTS IFX MAPPING TABLE FOR MERCHANT RELATIONS ISO20022 MAPPING TABLE FOR CARD CAPTURE ISO20022 MAPPING TABLE FOR CARD AUTHORIZATION BUSINESS SCENARIO MAPPING- CARDS CARD AUTHORIZATION MERCHANT SETTLEMENT DISPUTED CARD TRANSACTION CARD BILLING CYCLE AWARD REWARD POINTS MAPPING ARTIFACTS CONCLUSION FINDINGS Singapore Management University Page 3 of 45

4 BAIN IFX ISO20022 (Cards) 5.2 FUTURE WORK APPENDIX Singapore Management University Page 4 of 45

5 BAIN IFX ISO20022 (Cards) 1. Introduction 1.1 DEFINITIONS The following terms are used in this document: Term BIAN IFX ISO Meaning Banking Industry Architecture Network Interactive Financial eexchange International Organization of Standardization 1.2 AUDIENCE This mapping document targets the following audience. Audience Business Stakeholders Enterprise & Domain Architecture Project Team Detailed Designers Intended Purpose 1.3 REFERENCE The following documents were referenced for this project: Ref# Document Description/Location 1 How_to-Guide_SL_v4 BIAN bian.org 2 FINALBIAN_CMU_Final_Repo BIAN bian.org rt, BIAN_IFX_Proof_of_Concept 3 BIAN Cards Draft Scenarios July BIAN MDR_Part1_AcceptorToAcquire ISO r_maintenance_2014_ Version 4.0 Service Operations BIAN - January Scripted_ISO_20022_ppt_long_v ersion_v75 7 IFX documents and artifacts cs.jsp 8 ISO20022 and EPAS for For Dummies 9 SMU Teaching Bank Reference Architecture Nexo A.I.S.B.L 0tBank%20Reference%20Architecture.pdf Singapore Management University Page 5 of 45

6 BAIN IFX ISO20022 (Cards) 1.4 BACKGROUND The Banking Industry Architecture Network (BIAN) is an independent, memberowned, not-for-profit association, founded in 2008, by financial institutions, IT service providers and educational institutions with the purpose of defining Service Oriented Architecture (SOA) based standards and semantic definitions for IT services for the banking industry. BIAN defines its mission as to assist and guide the banking industry towards a consensus-based approach to achieving the vision of a flexible architecture which is closely aligned with business objectives of increased agility and reduced cost by asking leading banks to share their requirements for core services and leading software and services vendors to implement these services based on formally defined semantics. The Banking Industry Architecture Network (BIAN) has defined an SOA based standard for IT services in the banking industry, called Service Landscape (SL) 4.0. This standard presents a business architecture perspective, which is independent from system implementation. To map the SL 4.0 to underlying systems architecture, additional design artifacts are required. One key requirement is mapping the high level semantic BIAN Service Operations to system messages. The initial study was done as part of the CMU Capstone and this is to further expand the mapping coverage to other Service Domains. This would demonstrate the value Banks can achieve by using the standards as a point of reference to 1: Accelerate development life cycle 2: Scope of services offered to, provided by 3: Isolate legacy systems by defining them as services 4: Reducing redundancy in systems performing overlapping roles 1.5 OBJECTIVE The objective of this project would be to deliver the mapping between IFX and ISO20022 using the BIAN Service Landscape as mediation (common point) between the two messaging standards. The focus To begin with, we shall research and compare the two industry Message Standards, and then, we map the Service Domains in the BIAN Architecture to the each message component of the message standards To obtain the project objectives, we shall adhere to the following steps: 1. Develop an understanding of the BIAN Cards Business Domain, Service Domains and the Service Operations. 2. Develop an understanding of the Message Standards ISO and IFX, overall understanding and deep dive into the Cards related Messages. Singapore Management University Page 6 of 45

7 BAIN IFX ISO20022 (Cards) 3. Map the Message Standards to the BIAN architecture based on the understanding of 1 and Mapping outcomes tables based on the study The focusing areas of each Message Standard (IFX and ISO 20022) are different. IFX has more maturity in the B2C (Bank-to-Consumer) domain and is a message object oriented model. ISO is focused mostly on B2B (Bank-to-Bank) transactions and is a scenariobased model. Our focus is on the Cards Business Domain and as the outcomes of the mapping exercises; we shall recognize the differences between Message Standards for the service domains. The basis of our mapping procedure of the Service Domains is derived from the study done by the CMU BIAN team and their recommendation as one of the future work. The scope of this project was also finalized based on recommendation from BIAN based on their priority, resource availability and project timeline. We have further included the Business Scenarios mapping to identify the message mapping to the Service Domain interactions based on Cards functionality 2 BIAN CARDS BUSINESS DOMAIN 2.1 THE SERVICE DOMAIN BIAN s approach is based on breaking all banking activity into a collection of discrete business capabilities called BIAN Service Domains. The collection of BIAN Service Domains is intended to be comprehensive so that any and all business activity can be supported by a suitable selection of Service Domains interacting through their associated service operations. A BIAN Service Domain Combines an Asset and a Use The technique used to isolate a BIAN Service Domain defines its associated business capability to be the combination of a type of action or use applied to a type of asset or entity. BIAN has identified a standard list of uses (called functional patterns) and has developed a hierarchical decomposition of the assets or entities (tangible and intangible) that may make up any bank. Each Service Domain combines a single primary functional pattern (for example maintain reference details, define and execute a plan ) with an asset or entity type (for example a piece of equipment, a customer relationship ). BIAN Service Domains are Elemental in Scope In order to define canonical capabilities each Service Domain must fulfil a single/elemental business role. If a Service Domain covers multiple functions then different combinations could apply in different deployment situations and the behaviors would cease to be canonical/standard. The functional patterns and asset decomposition mentioned in the previous section help identify elemental business roles, but some additional considerations are necessary to ensure the designs are indeed canonical for some specific banking activities. Singapore Management University Page 7 of 45

8 BAIN IFX ISO20022 (Cards) BIAN Service Domain s Share a Common Structure All Service Domains fulfil a unique business purpose acting as a service center providing access to their business capability through offered service operations and drawing on the services of other Service Domains as they may require. Every Service Domain has an operating pattern characterized by the handling of its Control Record. The Control Record reflects the combination of the Service Domain s functional pattern applied to its asset/entity type. A Control Record instance is created each time a Service Domain fulfils its role from inception to completion so for example the Service Domain with the functional pattern maintain reference details for the asset/entity type customer relationship will maintain a control record instance detailing the reference details for each customer for as long as they are known to the bank. 2.2 THE BUSINESS DOMAIN Business Activity is modelled as Service Domain Interactions Anything that goes on in a bank can be represented using a suitable selection of Service Domains and capturing the pattern of service interactions between them. The primary model representation captures transactional activity using the BIAN Business Scenario, similar in purpose to a high-level business process. The Business Scenario is a simple diagrammatic representation of the involved Service Domains and the archetypal flow of service interactions involved in handling/responding to a business event. A second representation of business activity currently being considered represents the background synchronization activity between Service Domains. Singapore Management University Page 8 of 45

9 BAIN IFX ISO20022 (Cards) 2.3 BUSINESS AREA Groups together a broad set of business capabilities Aspects of business activity that have similar supporting application and informationspecific needs 5 Business Areas Reference Data, Sales and Service, Operation and Execution, Risk and Compliance, Business Support 2.4 SERVICE OPERATION KEY CONCEPTS Way of Interaction between Service Domains in a Business Scenario. Ensure BIAN Specifications as Implementation agnostic Role of SD Control Record Functional Pattern Asset /Entity Responsibility items Reflects the combination of some asset or entity that the bank owns or has influence over and a specific action or function performed to that entity with the intent of Reflects the combination of the Service Domain s functional pattern applied to its asset/entity type Created each time a Service Domain fulfils its role from inception to completion is a pattern that is used to track the execution of the business purpose/role of the Service Domain The dominant type of business function performed. used to select a default set of appropriate service operation action terms The business object or entity type that the prior business function is applied to by the Service Domain They define the type of access or action performed through the associated service operation. The responsibility items for a Service Domain are organized into four responsibility item types Initialize & Register offered service operations associated with setting up, verifying and/or registering a new occurrence of the Service Domain s control record. Invocation & Execution offered service operations associated with the Service Domain performing tasks on an active or Singapore Management University Page 9 of 45

10 BAIN IFX ISO20022 (Cards) established control record instance(s) in response to an external request Maintain & Analyse delegated service operations called by the Service Domain in order to enable it to fulfil its business role Note these have not been captured in the v4.0 release Report & Notify offered service operations associated with providing scheduled and adhoc reporting or providing subscription based notifications to Service Domains MAPPING ACTIONS TO FUNCTIONAL PATTERNS From above matrix, we can map the functional patterns against the action to derive the possible service operations. Agree Terms functional pattern can be applied to an instance of the intangible asset type customer relationship. The associated Service Domain Customer Agreement is responsible for the initial set-up, maintenance, for supporting any updates and access to the agreement, all analysis and reporting up to and including the agreement s final termination. The naming convention of the Service Operations are driven by action, qualifier <action term> <control record> [<qualifier term>] E,g, initiatepaymentexecutiontransaction Action term = initiate, control record = PaymentExecutionTransaction Control record is derived from asset type and functional pattern Asset Type is Payment Execution (more precisely the capacity to execute payment transactions) Transaction is the functional pattern. Singapore Management University Page 10 of 45

11 BAIN IFX ISO20022 (Cards) More specialized service operations are defined and named with an additional optional qualifier term. For.e.g. Current Account fulfilment Service Domain there are several services like setting up a standing order or requesting a funds transfer,so requestcurrentaccountfulfilment would instead have own dedicated service operations e.g. requestcurrentaccountfulfilmentstandingorder. The asset type component of the Service Domain s control record is related to the object/data type of the message set to filter candidates. For example the asset type could be a customer relationship and so the candidate messages provide access to customer data The functional pattern component of the Service Domain s control record is used to further specialize the filtering of messages based on more tightly defined object/data attributes. For example the functional pattern could be agree terms and so the candidate messages covering customer data can be further filtered to those containing customer agreement/contract related data The service operation action term is mapped to the message objective/intended use. For example the service operation action term could be update or retrieve and this can be used to filter out messages intended for different purposes Input and Output Parameters Identifiers Any subject and/or subject attribute that may be referenced in order to isolate the pertinent control record instance. For example customer, location, product type, date/time, transaction reference. Depiction Primary content/payload referring to the information captured and maintained as part of a Service Domain s control record instance. Control lists the different possible control parameters and result details that define and/or qualify how the called service operation action is to be fulfilled. For example it could define the time at which to perform an action and/or qualify the specific type of action to be performed and provides the service call result if appropriate Analysis References derived information that may be calculated and maintained by the Service Domain, typically associated with the history and/or access activity for one or a combination of control record instances. Say for the customer agreement example, the Service Domain may maintain and provide on request analytical views of the make-up of the complete portfolio of all of the active customer agreements it maintains in terms of their properties, usage and processing status. States(Possible Post) Apart from the above, this is another parameter part of the Output parameter. Typical states and state changes can be defined and associated with the functional patterns providing an opportunity to identify and confirm the desired response from service operations 2.5 CARDS BUSINESS DOMAIN Service Domains are grouped into Business domains and these are further categorized into Business Areas. The focus area for this project would be The Cards Service Domain under the Consumer Products Business Domain. This is categorized under the Operations and Execution Business Area as shown below Singapore Management University Page 11 of 45

12 BAIN IFX ISO20022 (Cards) Operations and Execution Product Specific Fulfillment Cards Credit/Charge Card Card Authorization Card Capture Card Billing and Payment Merchant Relations Card Service Operations under consideration are as below. CREDIT /CHARGE CARD Orchestrate the scheduled maintenance and transactional activities associated with credit/debit card product fulfillment CARD AUTHORIZATIONS Execute the decision based authorization and recording of proposed card transactions through the merchant network CARD CAPTURE Capture the card payment transaction through the merchant network CARD BILLING AND PAYMENTS At the cycle time a collection of card customer accounts are accessed and billing details determine and sent out. Payments are tracked and the facility status updated accordingly MERCHANT RELATIONSHIP Administer the day to day interactions with merchants, in particular for coordination of case resolution 3 MESSAGE STANDARDS 3.1 IFX The Interactive Financial exchange (IFX) Business Message Specification is developed and maintained as a cooperative industry effort among major financial institutions, service providers, and information technology partners to achieve a single, open financial services industry standard. It provides a comprehensive message set for developing new financial industry services and software. It is an XML specification for financial transactions such as payment, merchant relationship etc. Singapore Management University Page 12 of 45

13 BAIN IFX ISO20022 (Cards) The IFX Specification has been designed to meet the following principles: Support a Broad Range of Financial Activities Support Financial Communications Among a Broad Range of Parties Support a Broad Range of Client Devices Based on modern Service Oriented principles Support Customers Using Multiple Client Devices Support Batch and Interactive Sessions International Support Platform and Transport Independent Customizable and Extensible Robust and Secure Service Oriented Architecture: The IFX Standard is based on a service-oriented architecture. The most fundamental assumption underlying the standard is that there are one or more services being offered by a service provider. A service provider may manage these services directly or may choose to partner with others to provide the service. Service Providers are typically financial institutions, their partners, vendors or outsource agents. IFX Messages are directed to a Service Provider, who may in turn redirect the message(s) to another service provider. Framework: The IFX Framework consists of an Object Framework, outlining the structure and common elements of message content and a Message Framework, which provides the structure of IFX compliant messages consumed and produced by service implementations. The IFX Business Message Specification is designed to operate in stateless, multi-tiered, service-oriented environments. The framework consists of Common Object Definitions with well-defined data semantics and a Request-Response message protocol, where each message is targeted to act upon one object and each response indicates success or failure to ensure common understanding of object states after each attempted or successful message operation. Standard Message Protocol Request-Response-Status Common Object Definitions with well defined data semantics IFX Message Framework Singapore Management University Page 13 of 45

14 BAIN IFX ISO20022 (Cards) Object Model: IFX objects are the "representation of record" or current state of an IFX interaction. IFX interactions cause IFX objects to be created, modified and destroyed. These interactions are recorded in the form of an IFX object. Most IFX interactions start with an Add message that creates a new object and may be followed by any number of subsequent messages, which interact with the object. The primary objective in designing an IFX object is to accurately represent the chosen business process so that its execution can be accurately recorded. IFX Objects are constructed using the following building blocks: Element - The most basic unit of data in the IFX Specification to define a single piece of information (of a specific data type) that is passed between the client and the server. Aggregate - A group of related elements to provide a mechanism for coding logic rules and a convenient method to refer to related information using a single name. A full object xxx can be represented by an xxxrec aggregate that can consists of: Representation Meaning Description xxxid (Mandatory) xxxinfo (Mandatory) xxxenvr (Optional) xxxauth (Optional) xxxstatus (Mandatory) xxxref (Optional) xxxkeys (Optional) Identifier Information Environmental data Authentication Information Current Status Reference Other unique identifiers An Identifier is an unstructured string of 36 narrow characters that is unique to an IFX object. All IFX objects must have an Identifier A mandatory required aggregate that contains the client modifiable properties of the object. it will usually define the key features of an IFX object. The Environment aggregate describes the environmental data that is defined by the server. This data is generally technical data, such as the time of the creation of an object (CreatedDt), the time of the object's latest update (LastUpdateDt), and the owner of the object etc. Optional aggregate that contains authentication information and requirements for the object. This aggregate is used selectively, as it contains passwords, PINs, certificates A required aggregate, the Status segment contains the current state of the object. Any object that is persistent must have a status. A reference segment is an indirect reference to another object; either that object's Id The Keys segment describes unique identifiers that reference and object. There are often business attributes that can uniquely address an object e.g. an Account Number Singapore Management University Page 14 of 45

15 BAIN IFX ISO20022 (Cards) xxxsel (Optional) contain a list of Ids of other IFX objects An object may also include an SvcIdent aggregate to specify the ultimate owner of the object. IFX Path is a notation described by the forward slash character (/), and is used to navigate across IFX objects, allowing us to refer to individual components while still preserving the objects hierarchical structure. IFX objects can be represented in three standard forms. These forms represent the entire set of object data relevant to the function being performed. The three standard forms are: View Name Description Object Object Rec (DebitRec) A complete object view including all segments. Status Object The status of the object including the Id and Auth Selection Segment StatusRec(DebitStatusRec) Object AuthRec(DebitAuthRec) A selection segment is an indirect reference to a collection of other objects. On the wire, it will Status segments The auth information about the object including the Id and Auth segments. Message Model: Like objects, all IFX messages are patterned after a common set of conceptual IFX messages. These message implement a well defined set of actions on IFX objects. The use of a common pattern related behaviors is intended to make programming of IFX systems easier and their operation more predictable. Following methods are available for composting IFX messages: Name Message Description Add Add The xxxadd Messages support creating a new instance of the specified xxx object. Advise Advise The xxx Advise Message is used to notify interested parties that an xxx object was created or modified. Aud Audit The xxx Audit Message supports the ability for the client to trace the message history for all changes affecting the specified xxx object. AuthInq AuthMod Authorization Inquiry Authorization Modification The xxx Authorization Inquiry Message is used to request an inquiry of authorization information for the specified xxx object. The xxx Authorization Modify Message is used to change authorization information for the specified xxx object. Can Cancel The xxx Cancel Message, often used on transactional objects, is used by a client to cancel a previously added instance of xxx object, or to Singapore Management University Page 15 of 45

16 BAIN IFX ISO20022 (Cards) cancel an existing scheduled object. Del Delete The xxx Delete Message removes an existing object. Inq Inquiry The Inquiry Message is used to search for and/or gain information about the current state of existing xxx objects. Mod Modify The xxx Modify Message is used to modify the information previously supplied in an xxx Add Request. Rev Reversal The xxx Reversal Message is used to reverse the effect of a message. StatusInq Status Inquiry The xxx Status Inquiry Message allows a user to inquire on the status of xxx object. StatusMod Status Modification The xxx Status Modify Message allows a user to change the status of xxx object. Sync Sync The xxx Sync Messages provide the ability for a client device to be brought up to date on changes made to the specified xxx object. The framework is depicted below with some examples of defined IFX Objects. All data exchanges are handled with a request-response protocol. Message headers are used for message routing, while all response messages include indicators for the status of the action requested. If a response is not desired by a service, it can simply ignore it Singapore Management University Page 16 of 45

17 BAIN IFX ISO20022 (Cards) 3.2 ISO ISO Universal financial industry message scheme is the international standard that defines the ISO platform for the development of financial message standards. Its business modelling approach allows users and developers to represent financial business processes and underlying transactions in a formal but syntax-independent notation. These business transaction models are the "real" business standards. They can be converted into physical messages in the desired syntax. The ISO standard offered a common way of using XML and a way to shield investments from future syntax changes by proposing a common business modelling methodology to capture, analyze and syntax-independently describe the business processes of potential users and their information needs The standard itself describes the development methodology, the registration process and the organization of the central financial repository that contains the ISO messages and their components. The ISO standard consists of eight parts: Part 1: Meta model Part 2: UML profile Part 3: Modelling Part 4: XML schema generation Part 5: Reverse engineering Part 6: Message transport characteristics Part 7: Registration Part 8: ASN.1 generation The ISO approval and registration process involves three kinds of registration bodies: the Registration Management Group (RMG), the Registration Authority (RA) and the Standards Evaluation Groups (SEGs). The RA and SEGs work together to validate and process the registration requests authorized by the RMG The list of Business Areas already defined by the Registration Authority to classify ISO Message Definitions and the corresponding four-character code used in the Message Identifier1 of related ISO Message Definitions. Payments, Securities, Trade Services, Cards, FX Singapore Management University Page 17 of 45

18 BAIN IFX ISO20022 (Cards) ISO Business Components Business Component Represents a key part of business notion. Business Component is uniquely identified in the dictionary Business Element Business Element is uniquely identified in its Business Component. Account (Account holder information, address, and Account balance) Business Association It represents semantic relation between two Business Components. Uniquely identified in the scope of two Business Components Business Role A functional role played by a business actor in a particular Business Process. A Business Role is uniquely identified in the Dictionary ISO Message Components Data Type & Data Type Representations Data Type is the unambiguous specification of the set of valid values of a Message Element Representation is characterized by a set of technical information required for implementation Message Component Message Component may be defined as a "Choice" component. Message Component is uniquely identified in the Dictionary Message Element Message Element is uniquely identified in its Message / Choice Component. Message Element may be repeated in an instance of a Message Component Constraint A constraint attached to a Business or Message Component. ExchangeConversionRule (applied to Business Component CurrencyExchange) Singapore Management University Page 18 of 45

19 BAIN IFX ISO20022 (Cards) 4 Mapping Procedure In order to understand more about how service domains interact with each other and how they IFX and ISO20022 can be mapped to BIAN card services domain, the following approach was taken: IFX: Registration with IFX on Download the documentation and schema (XSD) from IFX forum from By default, one can t download the schema and useful documentation. So we contacted IFX administration. President of IFX Mr. Rich is very kind enough and he gave the elevated rights to download the relevant material from IFX Forum. IFX community forum is also useful to ask any questions related to IFX. ( Once we had all the relevant information, we started mapping IFX and BIAN card service domain and related business scenarios. ISO2022: Singapore Management University Page 19 of 45

20 BAIN IFX ISO20022 (Cards) Reached out to Cards SEG Convener Mr. William Vanobberghen to review the development status of the wider portfolio of messages to finalize the mapping scope Download the MDR of applicable messages to map the cards messages against the Service operations input parameters Support group ISO20022RA for ISO related support. Once we had the double set of ISO cards messages developed by nexo A.I.S.B.L. (previously EPASOrg) under the name Cards Payments Exchanges (CAPE) we proceed with the mapping ISO and BIAN card service Domain. BIAN: Reached out to Mr Guy from BIAN for the latest set of documents on BIAN V4.0 Subsequent review sessions to confirm our understanding 4.1 MAPPING TABLES FOR CARD SERVICE DOMAINS The mapping results are shown as below Singapore Management University Page 20 of 45

21 BAIN IFX ISO20022 (Cards) IFX MAPPING TABLE FOR CARD FACILITY IFX MAPPING TABLE FOR CARD AUTHORIZATION Singapore Management University Page 21 of 45

22 BAIN IFX ISO20022 (Cards) IFX MAPPING TABLE FOR CARD CAPTURE IFX MAPPING TABLE FOR CARD BILLING & PAYMENTS Singapore Management University Page 22 of 45

23 BAIN IFX ISO20022 (Cards) IFX MAPPING TABLE FOR MERCHANT RELATIONS ISO20022 MAPPING TABLE FOR CARD CAPTURE Grey indicates GAP BIAN ISO Control Record Mapped Area Lifecycle /Business Service Domain Offered Services Actions Domain/ Element Card Capture After receiving This candidate authorization, the service domain card customer adds a supports the point of service payment to sale network capture the price of a meal of authorized card and makes the transactions, payment through the initiating the merchant financial appropriate principal capture system debit and any associated transaction fees from the card facility Initiate Update execute Request Notify Retrieve initiatecredit/chargecardfinan cialcapturetransaction updatecredit/chargecardfinan cialcapturetransaction executecredit/chargecardfina ncialcapturetransaction Asset Type Credit/ChargeCardFinanci alcapture requestcredit/chargecardfina ncialcapturetransaction notifycredit/chargecardfinanc ialcapturetransaction retrievecredit/chargecardfina ncialcapturetransaction Functional Pattern TRANSACTION CAAA CAAA CAAA Mapped Message AcceptorBatchTransfer(caaa Capture via batch of offline only Authorized 4) Transactions AccceptorBatchTransferResponse(caa a ) AcceptorReconcilationRequest(caaa ) Mapping Explaination Process and respond to Batch transfer capture requests Sending acceptors reconciliation data Singapore Management University Page 23 of 45

24 BAIN IFX ISO20022 (Cards) ISO20022 MAPPING TABLE FOR CARD AUTHORIZATION Grey indicates GAP BIAN ISO Control Record Service Domain Card Authorization Execute the decision based authorization and recording of proposed card transactions through the merchant network A credit card customer makes a large purchase, the card authorization triggers a verbal check of the customer details for security and the authorization is given Lifecycle Actions Activate Configure Record Evaluate Authorize Retrieve Offered Services activatecredit/chargecardaut horizationassessment configurecredit/chargecardau thorizationassessment recordcredit/chargecardautho rizationassessment evaluatecredit/chargecardaut horizationassessment authorizecredit/chargecardau thorizationassessment retrievecredit/chargecardauth orizationassessment Asset Type Credit/ChargeCardAu thorization Functional Pattern ASSESSMENT Mapped Area /Business Domain/ Element CAAA CAAA CAAA Mapped Message AcceptorAuthorisationRequest AcceptorAuthorisationRequest -To request (caaa ,acceptorauthorisatio authorisation of a card payment transaction; nrequestv04) AcceptorCancellationRequest -To request the AcceptorCancellationRequest cancellation of the transaction (caaa ,acceptorcancellatio nrequestv04) AcceptorCompletionAdviseResponse(c aa ) Mapping Explaination Record/ respond to a advise received from the acceptor on the outcome of the card transaction AcceptorAuthorisationResponse AcceptorAuthorisationResponse -To return the (caaa ,acceptorauthorisatio results of an AcceptorAuthorisationRequest nresponsev04) AcceptorCancellationResponse -To return the AcceptorCancellationResponse results of an AcceptorCancellationRequest (caaa ,acceptorcancellatio nresponsev04) Singapore Management University Page 24 of 45

25 BAIN IFX ISO20022 (Cards) 4.2 BUSINESS SCENARIO MAPPING- CARDS Card business scenarios examples are considered in this section. These are representation of interactions between the various service domains to achieve some of the cards business functions. These interactions are then mapped to the corresponding IFX Objects and messages. This provides a powerful mechanism to define the roles and interactions that the Service Domains support by example. Selection of Business scenario Currently 4 Business Scenarios for Cards have been published by BIAN, namely Card Billing Cycle, Card Use Authorization, Disputed Card Transaction, New Card Setup. Since New Card Setup has been already worked on by IFX, we have considered the other three scenarios. We have in addition considered a draft Card Scenario of Merchant settlement (yet to be published by BIAN)and attempted to contribute by introducing a new scenario from our end Award Reward Points Mapping exercise Select a business scenario from pool of scenarios from Cards on BIAN website Identify all service domains assets, functional patterns involved in the life cycle of business operation Select IFX/ISO object and messages corresponding to BIAN assets and functional patterns Match compatible IFX/ISO entities with BIAN entities at higher level Validate with Subject Matter Experts Representation The approach is to depict the BIAN Business Scenario representation with the financial messages exchange corresponding to the service domain interactions.thus by retaining the BIAN Service Domains( instead of the Financial Messaging objects say from IFX) provides a direct understanding of the mapping and ability to validate the fitment of the messages to service operations. This is key. Thus as first step we indicate the BIAN Business Scenario and a similar representation using IFX messages followed by an equivalent mapping table Singapore Management University Page 25 of 45

26 BAIN IFX ISO20022 (Cards) CARD AUTHORIZATION BIAN Business Scenario Diagram ( The above business scenario of the Cards domain represents process of a card authorization and captures the transaction Singapore Management University Page 26 of 45

27 BAIN IFX ISO20022 (Cards) IFX Sequence Diagram Singapore Management University Page 27 of 45

28 BAIN IFX ISO20022 (Cards) Mapping Table Singapore Management University Page 28 of 45

29 BAIN IFX ISO20022 (Cards) MERCHANT SETTLEMENT BIAN Sequence Diagram The above business scenario of the Cards domain represent process of the settlement, reconciliation of Merchant invoice and initiating a payment order. Singapore Management University Page 29 of 45

30 BAIN IFX ISO20022 (Cards) IFX Sequence Diagram Singapore Management University Page 30 of 45

31 BAIN IFX ISO20022 (Cards) Mapping Table Singapore Management University Page 31 of 45

32 BAIN IFX ISO20022 (Cards) DISPUTED CARD TRANSACTION BIAN Sequence Diagram Singapore Management University Page 32 of 45

33 BAIN IFX ISO20022 (Cards) IFX Sequence Diagram Singapore Management University Page 33 of 45

34 BAIN IFX ISO20022 (Cards) Mapping Table Singapore Management University Page 34 of 45

35 BAIN IFX ISO20022 (Cards) CARD BILLING CYCLE BIAN Sequence Diagram Singapore Management University Page 35 of 45

36 BAIN IFX ISO20022 (Cards) IFX Sequence Diagram Singapore Management University Page 36 of 45

37 BAIN IFX ISO20022 (Cards) Mapping Table Singapore Management University Page 37 of 45

38 BAIN IFX ISO20022 (Cards) AWARD REWARD POINTS BIAN Sequence Diagram Singapore Management University Page 38 of 45

39 BAIN IFX ISO20022 (Cards) IFX Sequence Diagram Singapore Management University Page 39 of 45

40 BAIN IFX ISO20022 (Cards) Mapping Table Singapore Management University Page 40 of 45

41 BAIN IFX ISO20022 (Cards) 4.3 MAPPING ARTIFACTS All the related mapping details including message mapping can be found in the spread sheet. WorkingNotes_versio n2.0.xlsx 5 CONCLUSION 5.1 FINDINGS IFX The BIAN-defined Cards Service domains can be mapped to, and implemented using, a pre-existing service oriented messaging standard o We were able implement the mapping tables for the IFX messages being an object oriented model o Same IFX objects are involved in several different Service Domains. For e.g. the IFX object Party was used across multiple Service Domains as part of the Business Scenario mapping, thus bringing out the granularity or fine grain nature of the BIAN services compared to existing IFX objects. ISO In ISO Cards messages developed have only two Business areas published by RA. Thus mapping of messages to BIAN Cards Service Domain is very limited o ISO Cards Authorization scope is from Merchant to Acquirer perspective and not from the issuer perspective o ISO Cards Business Scenarios that were considered from BIAN had no mapping on ISO 20022; all are gaps but for (The payment related Service Domains) o Regarding the Terminal handling and management ISO have the related message areas which do not have coverage on BIAN o Clearly extensive B2B coverages but limited B2C coverage BIAN BIAN 4.0 Landscape the latest version published in March 2015 was used and this impacted as there were changes compared to the 3.5 version initially considered. The proposal was further modified to cover the latest version and this Land scape had changes impacting the Cards Service Domain although minimal Singapore Management University Page 41 of 45

42 BAIN IFX ISO20022 (Cards) Certain Life cycle actions associated by BIAN in the Cards Service Operations were observed to be not-applicable. o For e.g. the Card authorization service domain, 2 actions are currently mapped to operations EVALUTE and AUTHORIZE. Evaluate is not applicable for this domain. Hence a closer review is required similarly for other domains BIAN Working Groups review and refine the candidate content over time these descriptions should be improved. Mappings are greatly influenced by Depiction input parameters and Control Parameters of the Service Messages and are drivers in identifying the exact message mapping. We realized that Fraud monitoring, reward redemption, transaction authorization, token inventory are scoped as Service Domains for cross product operations and certain Service Domains dedicated to administration did not find an equivalent object or message across both messaging formats (Rewards Administration service domain) 5.2 FUTURE WORK Expand mapping to other Card Business Scenarios Further scenarios can be covered related to Card to ensure functional coverage of the Domain. Scenarios on Merchant Onboarding,Terminal Management on POS,Fraud case management, Commercial cards, Non-Monetary events as in Credit limit increase, supplementary card issuance, card upgrade etc., Card Not present and NFC related transaction processing can be covered to bring out the Service Domain interactions and corresponding mapping to message formats, thus identifying gaps Repeatable procedures can be followed as mentioned in this document. Detailed Mapping on ISO messages BIAN Currently as mentioned one of our findings the ISO messages are very limited for the Cards Domain. But there are ongoing developments projects will offer a wider portfolio of messages as confirmed by ISO making the mapping activities effective and thus bringing out the gaps. ISO TC68/SC7/TG1 is working on the reverse engineering of the ISO 8583 messages and has submitted to the ISO RA a first set of 13 candidate messages. These messages as planned this year to be submitted to the Cards SEG for approval and official publication. Singapore Management University Page 42 of 45

43 BAIN IFX ISO20022 (Cards) The IFX Forum and Nexo are developing together ISO messages for ATM Interface for Transaction Processing and ATM Management. They submitted to ISO RA a first set of 21 candidate messages that they will also soon be in a position to submit to the Cards SEG for approval. China UnionPay introduced a project to develop ISO messages covering Dispute Resolution in Cards Fee Collection, ISO expects to receive the candidate messages in the near future. 2014, Nexo introduced a project for the development of ISO messages for Payment Tokens Management Exchanges (tokenization). This should also bring in related messages on board Implementing Model on SMU Teaching Bank SMU has embarked on a multiyear programme entitled SMU Bank for Financial Services Education, referred to as SMU Teaching Bank (or SMU tbank ). Starting from a clean sheet, we are building a teaching bank from the ground up, using today s architecture best practices. The mission of SMU tbank is to become a world class teaching bank, generating an on-going supply of undergrad and postgrad student projects whereby classroom learning outcomes can be put into practice, leveraging industry leading banking software and enterprise platforms. SMU tbank is a Service Oriented Architecture (SOA) implementation. Students develop banking applications (eg; Branch Teller, Internet Banking, Mobile Banking, General Ledger, Interbank Payments, etc.) that reuse services exposed via an Enterprise Service Bus (ESB). Using this architecture we are able to demonstrate large-scale change scenarios such as; a core banking system replacement, a new payments messaging standard, a bank merger whereby multiple vendor products need to coexist. SMU tbank is used in the classroom to teach banking concepts as well as architecture best practices. The SMU tbank applications are deployed onto a public cloud, and are available for use by other learning institutions. At SMU- SIS, we believe we are the only university in the world that has gone to the extent of building a fully functioning online bank for teaching purposes. In our next phase of development, SMU tbank will include an unsecured lending product for retail customers (essentially a credit card, without the plastic). The content delivered by this capstone project will be used to guide the development of this new product. Singapore Management University Page 43 of 45

44 BAIN IFX ISO20022 (Cards) 6 APPENDIX Service Domains involved in Cards Business Scenarios Singapore Management University Page 44 of 45

45 BAIN IFX ISO20022 (Cards) Service Domains Landscape in V4 Singapore Management University Page 45 of 45