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
thJune2015
Approval
Title Name Signature Date
Implementation of Financial Message Standards to BIAN Architecture
Alan Megargel 15th Jun 2015
VERSION HISTORY
Version Version Date Change Description Author
1.0 25th Apr 2015 - Initial Report Mukund
Premchandar, Sunil Bansal
1.1 11th May 2015 - Mid Term Report Mukund
Premchandar, Sunil Bansal
1.2 15th June 2015 - Final Report Mukund
Premchandar, Sunil Bansal 1.3 17th 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 - 41-42 Conclusion section
Mukund Premchandar, Sunil Bansal
1.4 19th June 2015 Updated reference to SMU Teaching Bank on page 43
Table of Contents Approval ... 2 VERSION HISTORY ... 2 1. Introduction ... 5 1.1 DEFINITIONS ... 5 1.2 AUDIENCE ... 5 1.3 REFERENCE ... 5 1.4 BACKGROUND ... 6 1.5 OBJECTIVE ... 6
2 BIAN–CARDS BUSINESS DOMAIN ... 7
2.1 THE SERVICE DOMAIN ... 7
2.2 THE BUSINESS DOMAIN ... 8
2.3 BUSINESSAREA ... 9
2.4 SERVICE OPERATION ... 9
2.4.1 KEY CONCEPTS ... 9
2.4.2 MAPPING ACTIONS TO FUNCTIONAL PATTERNS ... 10
2.5 CARDS BUSINESS DOMAIN ... 11
3 MESSAGE STANDARDS ... 12
3.1 IFX ... 12
3.2 ISO20022 ... 17
4 Mapping Procedure ... 19
4.1 MAPPING TABLES FOR CARD SERVICE DOMAINS ... 20
4.1.1 IFXMAPPING TABLE FOR CARD FACILITY ... 21
4.1.2 IFXMAPPING TABLE FOR CARD AUTHORIZATION ... 21
4.1.3 IFXMAPPING TABLE FOR CARD CAPTURE ... 22
4.1.4 IFXMAPPING TABLE FOR CARD BILLING &PAYMENTS ... 22
4.1.5 IFXMAPPING TABLE FOR MERCHANT RELATIONS ... 23
4.1.6 ISO20022MAPPING TABLE FOR CARD CAPTURE ... 23
4.1.7 ISO20022MAPPING TABLE FOR CARD AUTHORIZATION ... 24
4.2 BUSINESS SCENARIO MAPPING-CARDS ... 25
4.2.1 CARD AUTHORIZATION ... 26
4.2.2 MERCHANT SETTLEMENT... 29
4.2.3 DISPUTED CARD TRANSACTION ... 32
4.2.4 CARD BILLING CYCLE ... 35
4.2.5 AWARD REWARD POINTS ... 38
4.3 MAPPING ARTIFACTS ... 41
5 CONCLUSION ... 41
5.2 FUTURE WORK ... 42 6 APPENDIX ... 44
1.
Introduction
1.1 DEFINITIONS
The following terms are used in this document:
Term Meaning
BIAN Banking Industry Architecture Network
IFX Interactive Financial eExchange
ISO International Organization of Standardization 1.2 AUDIENCE
This mapping document targets the following audience.
Audience IntendedPurpose Business Stakeholders
Enterprise & Domain Architecture
Project Team Detailed Designers 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
rt, BIAN_IFX_Proof_of_Concept
BIAN bian.org 3 BIAN Cards Draft Scenarios July
2014
BIAN 4 MDR_Part1_AcceptorToAcquire
r_Maintenance_2014_2015
ISO20022 - www.iso20022.org 5 Version 4.0 Service Operations
January 25 2015
BIAN - https://bian.org/servicelandscape-4-0/ 6 Scripted_ISO_20022_ppt_long_v
ersion_v75
www.iso20022.org
7 IFX documents and artifacts http://bms.ifxforum.org/rel2_3/content/contents.jsp http://bms.ifxforum.org/rel2_3/content/SubscriberDo cs.jsp
8 ISO20022 and EPAS for For Dummies
Nexo A.I.S.B.L 9 SMU Teaching Bank Reference
Architecture
http://tbankonline.com/documentation/SMU%2 0tBank%20Reference%20Architecture.pdf
1.4 BACKGROUND
The Banking Industry Architecture Network (BIAN) is an independent, member-owned, 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 20022 and IFX, overall understanding and deep dive into the Cards related Messages.
3. Map the Message Standards to the BIAN architecture based on the understanding of 1 and 2.
4. 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 20022 is focused mostly on B2B (Bank-to-Bank) transactions and is a scenario-based 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
–
C
ARDS
B
USINESS
D
OMAIN
2.1THE 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.
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.2THE 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.
2.3BUSINESSAREA
Groups together a broad set of business capabilities
Aspects of business activity that have similar supporting application and information-specific needs
5 Business Areas
Reference Data, Sales and Service, Operation and Execution, Risk and Compliance, Business Support
2.4SERVICE OPERATION
2.4.1 KEY CONCEPTS
Way of Interaction between Service Domains in a Business Scenario. Ensure BIAN Specifications as Implementation agnostic
Role of SD
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
Control Record
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
Functional Pattern
The dominant type of business function performed.
used to select a default set of appropriate service operation action terms
Asset /Entity
The business object or entity type that the prior business function is applied to by the Service Domain
Responsibility items
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
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 ad-hoc reporting or providing subscription based notifications to Service Domains
2.4.2 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.
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.5CARDS 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
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
M
ESSAGE
S
TANDARDS
3.1IFX
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.
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.
IFX Message Framework
Common Object Definitions
with well defined data semantics
Standard Message Protocol
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)
Identifier An Identifier is an unstructured string of 36 narrow characters that is unique to an IFX object. All IFX objects must have an Identifier
xxxInfo (Mandatory)
Information A mandatory required aggregate that contains the client modifiable properties of the object. it will usually define the key features of an IFX object. xxxEnvr
(Optional)
Environmental data
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.
xxxAuth (Optional)
Authentication Information
Optional aggregate that contains authentication information and requirements for the object. This aggregate is used selectively, as it contains passwords, PINs, certificates
xxxStatus (Mandatory)
Current Status A required aggregate, the Status segment contains the current state of the object. Any object that is persistent must have a status.
xxxRef (Optional)
Reference A reference segment is an indirect reference to another object; either that object's Id
xxxKeys (Optional)
Other unique identifiers
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
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
StatusRec(DebitStatusRec)
The status of the object including the Id and Status segments
Auth Object
AuthRec(DebitAuthRec)
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 Authorization
Inquiry
The xxx Authorization Inquiry Message is used to request an inquiry of authorization information for the specified xxx object.
AuthMod Authorization Modification
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 xxxSel
(Optional)
Selection Segment
A selection segment is an indirect reference to a collection of other objects. On the wire, it will contain a list of Ids of other IFX objects
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
3.2ISO20022
ISO 20022 - 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 20022 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 20022 messages and their components. The ISO 20022 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 20022 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 20022 Message Definitions and the corresponding four-character code used in the Message Identifier1 of related ISO 20022 Message Definitions. Payments, Securities, Trade Services, Cards, FX
ISO 20022 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 20022 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)
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
http://bms.ifxforum.org/bmsadmin/registration/SelfRegistration.jsp
Download the documentation and schema (XSD) from IFX forum from
http://bms.ifxforum.org/rel2_3/content/contents.jsp
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.
(http://bms.ifxforum.org/forum/viewforum.php?f=1)
Once we had all the relevant information, we started mapping IFX and BIAN card service domain and related business scenarios.
Reached out to Cards SEG Convener Mr. William Vanobberghen ([email protected]) 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 <[email protected]> for ISO 200022 related support .
Once we had the double set of ISO 20022 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.1MAPPING TABLES FOR CARD SERVICE DOMAINS
Singapore Management University Page 22 of 45 School of Information Systems
4.1.6 ISO20022MAPPING TABLE FOR CARD CAPTURE Grey indicates GAP
Asset Type Functional Pattern
Initiate
initiateCredit/ChargeCardFinan
cialCaptureTransaction CAAA
AcceptorBatchTransfer(caaa.011.001.0 4)
Capture via batch of offline only Authorized Transactions Update updateCredit/ChargeCardFinan cialCaptureTransaction execute executeCredit/ChargeCardFina ncialCaptureTransaction CAAA AccceptorBatchTransferResponse(caa a.012.001.04)
Process and respond to Batch transfer capture requests Request requestCredit/ChargeCardFina ncialCaptureTransaction Notify notifyCredit/ChargeCardFinanc ialCaptureTransaction Retrieve retrieveCredit/ChargeCardFina ncialCaptureTransaction CAAA AcceptorReconcilationRequest(caaa.0 09.001.04)
Sending acceptors reconciliation data Card Capture Credit/ChargeCardFinancialCapture TRANSACTION
After receiving authorization, the card customer adds a
service payment to the price of a meal and makes the payment through the
merchant financial capture system
This candidate service domain supports the point of sale network capture of authorized card
transactions, initiating the appropriate principal
debit and any associated transaction fees from the card facility
BIAN ISO 20022
Service Domain Lifecycle
Actions Offered Services
Control Record Mapped Area /Business
Domain/ Element
Singapore Management University Page 24 of 45 School of Information Systems
Grey indicates GAP
Asset Type Functional Pattern
Activate activateCredit/ChargeCardAut horizationAssessment CAAA AcceptorAuthorisationRequest (caaa.001.001.04,AcceptorAuthorisatio nRequestV04) AcceptorCancellationRequest (caaa.005.001.04,AcceptorCancellatio nRequestV04)
AcceptorAuthorisationRequest -To request authorisation of a card payment transaction; AcceptorCancellationRequest -To request the cancellation of the transaction
Configure configureCredit/ChargeCardAu thorizationAssessment Record recordCredit/ChargeCardAutho rizationAssessment CAAA AcceptorCompletionAdviseResponse(c aa.004.001.04)
Record/ respond to a advise received from the acceptor on the outcome of the card transaction
Evaluate evaluateCredit/ChargeCardAut horizationAssessment Authorize authorizeCredit/ChargeCardAu thorizationAssessment CAAA AcceptorAuthorisationResponse (caaa.002.001.04,AcceptorAuthorisatio nResponseV04) AcceptorCancellationResponse (caaa.006.001.04,AcceptorCancellatio nResponseV04)
AcceptorAuthorisationResponse -To return the results of an AcceptorAuthorisationRequest AcceptorCancellationResponse -To return the results of an AcceptorCancellationRequest
Retrieve
retrieveCredit/ChargeCardAuth orizationAssessment
Card Authorization Credit/ChargeCardAu
thorization ASSESSMENT 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
BIAN ISO 20022
Service Domain Lifecycle
Actions Offered Services
Control Record Mapped Area
/Business Domain/ Element
4.2BUSINESS 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 20022 object and messages corresponding to BIAN assets and functional patterns
• Match compatible IFX/ISO 20022 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 26 of 45 School of Information Systems
4.2.1 CARD AUTHORIZATION
BIAN Business Scenario Diagram (https://bian.org/servicelandscape-4-0/)
Singapore Management University Page 28 of 45 School of Information Systems
4.2.2 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 30 of 45 School of Information Systems
Singapore Management University Page 32 of 45 School of Information Systems
4.2.3 DISPUTED CARD TRANSACTION BIAN Sequence Diagram
IFX Sequence Diagram
Singapore Management University Page 34 of 45 School of Information Systems
4.2.4CARD BILLING CYCLE BIAN Sequence Diagram
Singapore Management University Page 36 of 45 School of Information Systems
Singapore Management University Page 38 of 45 School of Information Systems
Singapore Management University Page 40 of 45 School of Information Systems
4.3MAPPING ARTIFACTS
All the related mapping details including message mapping can be found in the spread sheet. WorkingNotes_versio n2.0.xlsx
5
CONCLUSION
5.1FINDINGS IFXThe 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 20022
In ISO 20022 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 20022 Cards Authorization scope is from Merchant to Acquirer
perspective and not from the issuer perspective
o ISO 20022 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
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.2FUTURE 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 20022 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
The IFX Forum and Nexo are developing together ISO 20022 messages for ATM Interface for Transaction Processing and ATM Management. They submitted to ISO 20022 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 20022 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 20022 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 44 of 45 School of Information Systems
