Financial Services Industry - Glossary of Terms

Pertaining to payments, financial message and data integration, processing and orchestration

Alternative Payments – This encompasses a range of disintermediated payment mechanisms arising mainly from the boom in internet and mobile device retail. Examples include PayPal, AmazonPay, ApplePay, Square, Dwolla, Klarna and many more.

Canonical ModelThis refers to a data structure that allows storage of information derived from a range of related payment or other financial messages or information. Typically the basis for the canonical model would be XML and would be built from a range of message structures typically using ISO 20022 defined elements (see ISO 20022 Canonical Model) although depending on the underlying predominant asset class it could be based on FIXML or FpML. Thus one data structure can be used for data received/sent in a large range of payment related financial messages. Typically although the data model is derived from XML it is usually persisted as a table or tables within a relational database.

CGI-MP (CGI)The Common Global Implementation – Market Practice industry forum (CGI-MP) aims to bring together Financial Institutions and Corporates to simplify the implementation and standardize the messaging relating to the payments domain between bank and their corporate customers.

Corporate In-House BankThis defines a structure within a corporate treasury department that performs many of the activities typically carried out by a commercial bank on behalf of the business. This will include such things as internal (between business units) payments and collections (possibly multi-currency), manage inter-company loans, engage in FX/MM instruments and trading in Derivatives for hedging purposes and provide liquidity management functions. It can also carry out functions such as “Pay on behalf of” (POBO) and “Receipt on behalf of” (ROBO) entities within the corporate organization.

Corporate to Bank ConnectivityThis refers to the connection of a Corporate Treasury to banking partner/s. As well as the legal and contractual activities (covering client due diligence checks such as KYC, Credit risk checks, defining SLAs and KPIs, etc.), technical on-boarding is a challenge associated with integration of a banks payment systems to the Corporate TMS/ERP systems, etc. ensuring both parties send/receive financial messages with agreed definitions for the various services being supplied. These may be purely account services i.e. managing payments and receipts, but potentially could cover trade finance activities, FX services, etc. Differing areas of the banks business are likely to be involved in the on-boarding for the specific bank functions.

EBAM (Electronic Bank Account Management)EBAM is the mechanism by which bank customers, typically corporate clients, can manage their bank accounts. This includes opening, closing, mandate maintenance and issuance of account reports by Banks.

ERP system integrationThis encompasses the process of integrating an Enterprise Resource Planning system within a corporate IT infrastructure.

Faster Payments – Faster Payments is the name of the UK Real Time Payments system offering customer payments of up to 250,000 GBP. It uses an ISO 8583 structured message format. It was one of the first such systems to be implemented going live in May 2008.

Financial Message StandardsThis general term refers to definitions of messages and in some cases message implementation guidelines (MIGs) for use in the FS sector published by officially recognized bodies e.g. ISO 20022, FIX, SWIFT FIN.

FIX MessagingFIX messaging formats are used in the capital markets sector covering a range of processes associated with financial markets trading and for a range of asset classes.

FpML MessagingFpML (Financial Products Markup Language) messaging formats are used in the capital markets sector covering OTC Derivatives.

Host to Host Connectivity This refers to the process of connecting a bank and corporate treasury department. In some cases for a large Corporate Treasury this may comprise multiple banking channels. See also Treasury System Channel Management and Corporate to Bank Connectivity.

Immediate PaymentsThis is another term often used synonymously for Real Time Payments.

ISO 20022 canonical model – This refers to a logical data structure designed to enable support for multiple data definitions required in a particular business area. For example an ISO 20022 Canonical model for payments would include a full set of payment related elements. Potentially input data is supplied in a range formats (with individual elements possibly being transformed to the corresponding standard canonical model format). Once stored in the standardized canonical structure the data can be used to more easily produce standard output formats. In the payments industry canonical models are commonly in an XML format.

ISO 20022 message integration/transformationThis typically refers to the process undertaken in an organization where legacy standards in use are migrated to the newer ISO 20022 message formats.

ISO 20022 message standardsThese are the message standards published by the ISO organization Technical Committee 68. The standards are defined as part of a business modeling methodology and the models are published as message schemas with the syntax typically XML (ASN. 1 is also available).

ISO 20022 message variants – Base Versions of ISO 20022 published messages (see ISO 20022 message standards) can be issued as variants. For example, variant messages may exclude portions of the message in order for it be more easily implemented yet still cover a high percentage of the business uses cases. Variant messages are defined in the nomenclature by the penultimate (italicized to highlight) number as shown in the following example for a credit/debit notification camt.054 message; camt.054.002.003 – This is the variant message 2 for the 3rd version of the camt.054 message. Baseline ISO 20022 versions issued are always variant number 1 that is 001.

ISO 20022 message version ISO 20022 messages are issued and updated on a periodic basis with the version number incremented accordingly. The version number is the final number in the ISO 20022 message naming structure. Thus in the following example for the Cash Management message Credit/Debit notification message, the 3rd version is denoted (italicized); camt.054.001.003

Legacy Payment System modernizationThis refers to the process of overhauling banking payment systems often built in-house on legacy hardware e.g. mainframe computers. This is often driven by increasing costs of maintenance, inadequate support for new functional requirements and general supplier risk reduction.

Market Data StandardsCovers the standards that define financial markets information including items such as stock (or other financial instrument) pricing information, volumes traded, and other reference data. The data standard may vary as defined by the various vendors of such data, all servicing financial institutions trading in the capital markets.

Payments Channel connectivity – This covers the various connections to external clearing and settlement channels an international bank may need to manage. As well as SWIFT for International Payments, they are likely to require local clearing channels connections to national ACH or Real Time Payments infrastructures, and also regionally for example SEPA in the Eurozone.

Payments Engine – see Payments Hub

Payments Factory – see Payments Hub

Payments HubTypically this refers to the centralization of all payments (both high and low value (bulk) processing within a Bank or even in a Corporate Treasury department. They may also be known as a Payments Factory or Engine.

Payment Message StandardsThis refers to the definition of the financial messages associated with credit or debit transfers. Typically these can be country or region specific. Some such as ISO 20022 or SWIFT FIN can be viewed as global standards.

Payments System IntegrationTypically this refers the process of migration to a new payment processing solution typically from a legacy application. It may also involve the consolidation of distributed systems to a central hub.

Payment orchestration This refers to the management and coordinated processing of a financial institution’s payments to/from internal core banking or treasury management systems and external channels (such as domestic/international settlement systems). It may comprise of one or more payment workflows.

Payment workflowThis refers to a sequence of payment processing activities from initiation of payment instruction through a series of touchpoints that may include AML checks (i.e. is the recipient of funds legitimate), account validation, balance checks, enrichment of payment information, etc.

Real-Time Payments (RTP)Real Time payments is the term describing payments between 2 parties, processed by a financial institution (typically a bank) over a payments infrastructure where the transfer of funds is near real time and irrevocable. Settlement of funds between the banks (participants of the RTP system) is carried out subsequent to the actual payment (deferred settlement). Modern RTP systems are typically utilising ISO 20022 based message formats.

SWIFT for CorporatesThis refers to the connectivity offered by SWIFT, a global provider of a secure financial messaging network, to Corporate entities to communicate with their banking partners. This enables Corporate Treasury departments to initiate payments more efficiently as well as receive standardized account information from their banking partners.

SWIFT Financial MessagingSWIFT is a global provider of interbank communication upon which financial messages can be securely exchanged. The messaging covers a range of financial services industry domains and typically the message types (MT) are ISO 7775 or ISO 15022 based but the move to adoption of ISO 20022 based formats is happening at pace.

SWIFT MT/MX – This refers to the ISO 20022 based messages published by SWIFT, known as MX and the transformation maps published by SWIFT to their comparable SWIFT MT (FIN) message formats.

SWIFT TransformationThis refers to the technical process of transforming one format used by an organization to one of the published SWIFT defined format, typically MT (or FIN) format, but could be to the SWIFT MX format, the SWIFT published ISO 20022 based message set.

SWIFT ValidationThis refers to the technical process of validating a sent or received message against published syntactic and/or semantic (business) rules.

T2S ISO 20022 migrationThe migration to new ISO 20022 based message formats from SWIFT FIN formats for post trade settlement processes is an ongoing project in the Eurozone managed under the auspices of the European Central Bank (ECB). The first organizations migrated to the new system in June 2015 and migration (in 4 waves) is due to be completed by February 2017.

TARGET2 ISO 20022 migrationThis refers to the planned* move by the TARGET Euro high value real time gross settlement payments infrastructure from SWIFT MT (FIN) message formats.

*The original published migration date of Nov 2017 has now been postponed in response to EU banks concerns.

TMS system integrationThis encompasses the integration of a Treasury Management System within a corporate IT infrastructure. Centralization of distributed (local) treasury functions may also be part of the integration exercise.

Treasury System Channel Management This refers to the management of multiple banking channels within a large Corporate Treasury. This may be on an individual banking and/or business domain level. A key aspect of this is compliance in meeting a banks required formats for payment initiation/account management/reporting and may involve transformation of formats. See also Host to Host Connectivity.