dsds
Overview
The Swiftflow package is composed of the following main functional components: the message parser, the enricher, the address parser and the geo locator. We add to that list the API endpoint even though it is strictly speaking a design component. Those components are packaged as a stateless application accessible via the API endpoint using a REST API. Internal calls between components are loosely coupled; while some components depend on the messaging standard, others are independent of it and must therefore be implemented in a modular way, thus allowing for isolated improvements or replacements.
API endpoint
This component consists of an HTTP server that exposes the Swiftflow functionality using a simple REST API whose usage is documented in the user guide.
Message parser
The message parser is responsible for transforming the input text received from the API endpoint into an in-memory object.
For the ISO15022 messages, it applies a layered parsing that corresponds to the various contexts listed here, namely by identifying the message type, the blocks, the sections, sub-sections and fields, and using public specifications1. At field level, it converts the field formatting rules into regular expressions to be able to achieve full parsing, while taking into account the presence of optional elements. Note that at this point, no additional parsing is performed that does not comply to the standard specifications. The extra parsing applied for instance within the free text fields occurs later in the process in the address parser.
In addition and depending on the field, the parser component will type the values according to their definition and pattern, when necessary converting the native string type into another primitive (int, float and timestamp) or complex type (array, map).
Finally, this component is also responsible for keeping the original structure of the object, namely by reflecting the nested nature of the input string (delimited by the 16R and 16S tags for ISO15022) in the output object.
Enricher
The enricher component is in charge of providing additional information that can be attached to values and context found in the message. Specifically, it normalizes the business dates (e.g. trade date, value date or settlement date) found in the message by attaching the timezone of the corresponding entity if that one is made available in form of a standardized bank identifier code (BIC2).
This allows for a precise timing of the business process activities which is crucial for providing time-related features to the process and detect anomalies or inefficiencies.
Address parser
The role of the address parser is to convert a party field, typically composed of elements like account number, entity names and address text, into a content that is ready for geolocation. To stay as general as possible and accommodate for the different variants (see here), this component assumes a low degree of structuration and makes use of a postal address parsing tool for its implementation, while applying custom heuristics specific to the context, so as to return a structured object.
Geo locator
The goal of this component is to find the country code associated with a given address field (or generally the geo coordinates). It uses open data3,4 while applying custom cleaning and processing steps. For instance, it may need to successively reduce the search scope of the incoming text address, so as to balance off precision (number of correct results over all candidates) and recall (returning enough candidates to capture to correct one). The exact strategies employed can be reconfigured to fit the data scope and objective metrics of the use case. This is the most demanding component in terms of disk and memory resources.