Journal of Internet Banking and Commerce ISSN: 1204-5357
ISSN: 1204-5357
+44-175-271-2024Sajindra Jayasena, Stephane Bressan, Stuart Madnick
Web: http://sajindrajayasena.com , http://www.comp.nus.edu.sg/~steph/, http://web.mit.edu/smadnick/www/home.html
Email: sajindraj@yahoo.com, steph@nus.edu.sg, smadnick@mit.edu,
Visit for more related articles at Journal of Internet Banking and Commerce
Effective, efficient and transparent interoperability is vital for the profitability and sustainability of the financial Industry. Merely adhering to a standard does not pay rich dividends when multiple institutions and geographical segments utilize different standards. Even when within one standard, one often finds different possible interpretations originating in the practices and cultural background of the various players.
Typically, a Financial Institution (FI) that is involved in the Electronic Bill Presentment and Payment Industry is faced with a multitude of standards such as IFX (Interactive Financial Exchange protocol)[10], OFX (Open Financial Exchange Protocol)[9] and the world wide inter-bank messaging protocol, SWIFT [11]. Making matters worse, the FI may have its own semantics for its internal systems that represent the same business domain but in a different context. In the rest of this paper we would be referring to the IFX, OFX and SWIFT standards in EBPP point of view as IFX, OFX and SWIFT context and the Internal financial system of a Financial Institution as an internal context.
The Price and Invoice concepts may be represented in different ways, e.g., excluding tax, with tax and fees, and even with interbank charges, resulting in definitional conflict due to contextual differences [1]. Interoperability of such definitional conflicts is vital in distinguishing intra-bank and inter-bank payment across borders. Further, different contextual heterogeneities exist on the currency, where in certain contexts like IFX and OFX; it is implicitly based on where the funds are directed to. As a result of different Account types and BANK/BRANCH code, financial institution would need to maintain complex mappings between different contexts. In addition, there can be data level heterogeneities like date formats and representations. Examples of possible conflicts are summarized in table 1. The columns in the table related to OFX, IFX, and SWIFT represents actual real-life conflicts and similarities that exists between those standards while the conflicts addressed under the internal schema refers to an hypothetical but realistic, financial system utilized by a Financial system that would interact between OFX, IFX and SWIFT standards.
Table 1: Some conflicts in different financial standards
The objective of this paper is to analyze how the COIN mediation technology [2, 3, and 8] could be applied to provide a declarative, transparent yet effective mediation solution to the potential sources of heterogeneity and conflicts that exist within and among the existing financial standards
Electronic Bill Presentment and Payment domain
The 'Electronic Bill Presentment any Payment ? (EBPP)? domain is a rich subset of the financial services messaging frameworks and it has a considerable amount of heterogeneities. The main standards are OFX, IFX for intra-bank payment schemes and SWIFT for inter-bank payment and funds transfer. These standards may interact in various ways, as depicted in Figure 1.
Figure 1: Some interfaces in EBPP
For brevity, in order to depict the usage of COIN in EBPP mediation in a practical scenario, we have broken down the analysis to three main areas that spans from a customer initiating a Bill payment and its subsequent verification by the Biller. The conflict analysis and mediation with the diverse financial standards have been analyzed with respect to the hypothetical internal system of a Financial Institution which could be an in-house developed system or third-party (off the shelf) system. This internal system is represented by the term ?internal context?. Following are the three main areas analyzed in the case study
• Mediation between an internal context and OFX context.
• Mediation between an internal context and IFX context.
• Mediation between an internal context and SWIFT context.
The IFX, OFX and SWIFT contexts represent the semantics and definitions adopted by IFX, OFX and SWIFT messaging frameworks respectively. SWIFT distinguishes intra European Union (EU) fund transfer and outside EU fund transfers for accounting for inter-bank charges.
Figure 2 represents the context independent, COIN domain ontology for the EBPP domain denoting the concepts used by IFX, OFX, SWIFT and financial institution?s own internal schema. This was constructed by exploring the business domain in EBPP and the relevant message handling semantics used in these diverse standards. The semantic types (entities) represent the business entities that encompass the main functionalities in EBPP Industry. The semantic types denote the entities and their relationships in the EBPP domain like Payment, Account etc. is-a relation denotes a inheritance relationship between semantic types. Attribute lines represents attributes a certain semantic type possesses (payment has payee, payer accounts, amount etc). Further the entities that constitute conflicts in these contexts are modeled through modifiers. As an example, the paymentAmount can include/exclude various taxes in different contextual representations and in SWIFT it would incur an additional inter-bank service charge. These are represented by COIN modifiers paymentScheme, includesInterBankCharge respectively. Further all monetary amounts would have conflict in different currency usage. This is modeled using the currency modifier for the supersemantic type moneyAmount. This represents how COIN models inheritance of contextual knowledge for different entities.
Figure 2: Domain Ontology for EBPP
The mediations that we focus in this section resemble some actual real life scenarios that are faced while attempting heterogeneous systems integration. In this exercise these heterogeneities were extracted by analyzing the standards documentation of SWIFT, IFX and OFX as well as from the conflicts we introduced in the internal context which is hypothetical yet resembles a real life internal EBPP system of a Financial Institution. In an actual scenario, the heterogeneities and mappings for the different mediation could be analyzed and formulated by a business analyst or a person in that caliber working for the respective Financial Institution. Following sections addresses each one of them separately.
Internal Schema vs. OFX
First we will look at the mediations attempted between OFX and an internal schema of a financial institution. Table 2 summarizes the heterogeneities identified in the two schemas. As denoted in COIN?s mediation strategy, the modifiers and relevant conversion functions are the main ingredients in facilitating the mediation for a particular heterogeneity exiting between two different contexts. As shown in the table, there are different types of heterogeneities between the two contexts. The significant conflicts are payment amount, currency type and Account code reference identifiers. They are discussed below.
Table 2: Conflicts in Internal and OFX contexts that were mediated using COIN
Payment amount - The mediation strategy for payment amount is as follows. The mediator needs to apply two conversion functions in order to obtain the mediated payment amount, namely the currency conversion inherited from the moneyAmount super semantic type, and the tax adjustment for the payment. For simplicity let?s assume that in both schemas the currency is denoted in three letter ISO 4217 format (i.e. USD, GBP, and EUR etc). Assume that the query ?select AMOUNT from PAYMENT? is called in OFX context;
In the COIN framework, the mediation formulas are translated into logical expressions of the COIN theoretical model [1]. Later these expressions are evaluated by a Prolog-based abduction engine [13]. The following describes the logical representation of the formula (1) for this example.
The formula below describes a non-commutative mediation of paymentType object depending on its modifier paymentScheme, in this case hold the values ?noTax? and ?withTax?. The Ctxt defines the destination context. The conversion in simple terms would be to retrieve the Rate for the tax ?GST? from the elevated relation ?OFX_TAX_TYPES_p' which is an elevation mapped to relation ?OFX_TAX_TYPES? under OFX Context (The destination context in this case) and utilizes in the tax calculation. The value predicate in the formula defines a value of a particular semantic object under a certain context.
The following logical representation describes how the value of? modifier currency for paymentAmount is obtained for OFX context dynamically through the relationships between semantic objects.
For example the predicate attr (Payment,payeeAct,Account) defines the attribute relationship ?payeeAct? between the Payment and Account semantic objects. This relation can be mapped to underlying relationships in different contexts as shown in the following logical representation.
The two statements correspond to how the attribute relation payeAcct has been elevated to two elevation relations with their attributes, mapped in INTERNAL and OFX contexts.
Account type code - This is represented as heterogeneity in enumerated data types in defining the account type codes in the three contexts. The following summarizes the enumerated data mapping in the three contexts. Since there can be more than two types of financial standards, rather than having mappings between each standard , we adopt a ?Indirect conversion with ontology inference? strategy [13] where we represent the different account types in the ontology itself and providing mapping between the context independent ontology?s enumerated type and the context sensitive type codes. The context model would then map each security type context construct into its corresponding security type ontology construct.
Therefore usage the above mapping from INTERNAL to OFX would be,
Internal Schema vs. IFX
After looking at some of the interoperability issues between internal context and OFX, now we would delve into the newer standard, IFX, which has more features and detailed representations.
Table 3 shows the different types of heterogeneities.
Both IFX and OFX handle complex business payment transactions for business customers. This requires incorporating multiple invoice details attached to the payment aggregates when both the biller and customer are business entities. The older OFX provides a basic mechanism of incorporating invoice details like invoice discounts, line items in invoices etc. But the newer IFX extends this by providing more elaborate aggregates constituting different tax schemes as well as fees (late fees, FoRex fees, etc.) that are applicable to invoice.
Mediating Invoice Amount
Each payment can have at least one invoice aggregate that represent the different invoices paid through a particular invoice. In an internal schema the invoice amount might be represented as the net amount, where the taxes and fees would be aggregated when the bill is presented or invoiced. But in the IFX context, the Invoice amount constitute of the various taxes and fees that could be added to the net amount.
Table 3: Conflicts between Internal and IFX contexts that were mediated using COIN
The mediation between the two invoice amounts represents an equational ontological conflict (EOC) [5] that would be resolved similar to the previous example.
Some readers may have so far considered that identifying and resolving semantic heterogeneity is a small matter of handling date formats, currency exchange, and other accounting conventions. We observe now that the net effect and accumulation of such small matters makes the programmer?s task impossible. A programmer not equipped with the COIN mediation system must devise and create complex conversion programs and queries. A programmer using the COIN mediation system can type the original query: ?select INVOICE_AMOUNT from INTERNAL_INVOICE? in IFX context and rely on COIN to automatically mediate the query. On the other hand the query generated by COIN, (which the developer would have had to code in the absence of COIN) is shown below.
It?s evident that the application gains in clarity of design and code, as well as in scalability. The sharing of domain knowledge, context descriptions, and conversion functions improve the knowledge independence of the programs and their maintainability.
Internal Schema vs. SWIFT context
The SWIFT protocol is mainly involved in inter-bank cross border transactions. Under SWIFT context, depending on whether the transaction is between financial institutions inside the EU or outside, a bank handling fee is credited to the payment amount. This can be modeled using the sub context concept of COIN. A sub context derives all the super context based modifier values while having specialized modifier values for extended features. The following logical formulas denote how this can be modeled in COIN
Then a query like ?select AMOUNT from PAYMENT? in outsideEU context called on a relation defined for internal context is resolved by adding the handling charges on top of the local applicable tax (inherited from SWIFT context) as denoted in the following mediated datalog.
It is important to remember that although datalog and prolog representations are used internally within COIN and shown in this paper, the actual COIN system provides a user-friendly interface so that a user need not know anything about these internal representations.
We identified different semantic, ontological heterogeneities that exist in different financial messaging standards and showed that mediation between these is not a trivial task, yet are critical and important to the globalization of the financial industry. We show that an effective answer is to have a mediation service that provides automatic and a transparent mediation without requiring the generation and regulation of a new single universally enforced standard.
The COIN approach is capable of mediating the different heterogeneities that exist in different financial standards and internal contexts of Financial Institutions. Our approach in modeling a business domain and mapping different contextual representations and values through a declarative manner demonstrates the extensibility and flexibility of the COIN framework.
Copyright © 2024 Research and Reviews, All Rights Reserved