For example, the supervisory authorities stipulate uninterrupted operation if the financial institution wants to process instant payments. We have experienced the resulting architectural challenges first-hand in our TRAVIC-Payment Hub. Add to this the numerous surrounding systems such as anti-money laundering or embargo and sanction lists, not to mention routing. Doing all of that in-house results in such high costs that many financial institutions would rather prefer not to do any payment processing at all and instead to have it done by a central institution within a large association. However, that is not an option if payments are to become a strategically important line of business.
Roundabout for payments
We have thus asked ourselves: what exactly is the "special ingredient" that financial institutions need to add to their payments systems in order to distinguish themselves from other competitors and be able to offer payment processing as their own product? This question is especially relevant if an institution applies as a service provider for corporate customers to process their payments in a specific region of the world. And lo and behold: in their core, many processes are quite similar from one financial institution to another. They mostly only differ with regard to the order the financial institutions perform them in. Following this insight, we have designed a payments platform that works like a roundabout. For each special function, there is an opportunity to "hop on" the platform in a different place, just like children on a fairground may hop on the roundabout anywhere they like (see Fig. 1).
TRAVIC-Payment Hub enables a financial institution to define any conceivable configuration. This applies both to the routing administration (which allows for almost any complexity of rule sets) and to the connected surrounding systems. But how does TRAVIC-Payment Hub know what is supposed to happen if, for example, the compliance system returns a certain status? Usually it is the surrounding systems that have to follow what the main system commands – so why should a financial institution, after possibly getting rid of one monolith in core processing, now acquire another in payments processing? The answer to this is an integrated workflow engine that has its own script language to connect the other systems comparatively easily – while also being independent of the manufacturer, i.e. of us.
The "Hub" in TRAVIC-Payment Hub is thus both a product name and a performance promise.
Software development inside out
In terms of technicality, we turn what would otherwise develop into "legacy" outwards. The implemented script language enables a financial institution to add its own business processes to TRAVIC-Payment Hub without having to open up the source code of the software. As technology and business aspects are separated, a significant part of software development thus moves from the sphere of the manufacturer into the sphere of the user. This means that the payments platform stays fit for release even though TRAVIC-Payment Hub may have to coordinate a complex network of surrounding systems. Additionally, the IT departments are not even tempted to develop too closely to the core payments processing and to run the risk of trying to modify something in one place and, in doing so, provoking a problem in another.
In practice, the procedure is as follows: TRAVIC-Payment Hub receives various statuses by the surrounding systems. The script language is used by in-house IT employees or the integration partner to define how payments with the respective statuses shall be handled. As soon as the workflow is fully defined, the system compiles the code so that TRAVIC-Payment Hub can start working. To this end, the workflow engine generates tasks which are then processed by an internal task engine. Here is a very simple example of how the script language developed by PPI for TRAVIC-Payment Hub handles OUR charges, i.e. determines whether the charges due may be enclosed with a payment and retained or whether a payment request must be created.
Status CHECKINBOUNDCHRGS {
if payment is inbound and (payment is ourCharges) then {
if payment is ourChargesReceived then {
just set status VALIDATERECEIVCHGS and leave step
}
if payment is correspondentChargeExpected then {
if payment is debitAuthorized then {
just set status CREATEADVICEOFCHGS and leave step
}
just set status CREATECHARGEREQ and leave step
}
}
just set status DONE and leave step
Introducing TRAVIC-Payment Hub
With the TRAVIC product suite, PPI covers the entire payments process of a financial institution, from incoming payments over interbank communication up to clearing. TRAVIC-Payment Hub handles the core processing of payments. Our solution works as customer bank and as clearing bank – even in parallel operation – and can process instant payments. Moreover, the solution can be operated on site and as outsourced high-availability software in cooperation with our infrastructure partners.
Author: Thomas Riedel
Further information:
- Using standard software like a customised solution? download expert article by Thomas Riedel and Markus Seeliger, courtesy of IT-Finanzmagazin (German)
- TRAVIC-Payment Hub for instant payments
- TRAVIC-Payment Hub for individual payments
0 comments:
Post a Comment