The challenge
One of Bally’s key providers of payment services is FreemarketFX with a connectivity strategy that mandates use of a REST API for statement reporting and payment initiation automation. Bally’s uses FreemaketFX to provide payments and banking services for 19 of its companies, holding 63 active bank accounts which are used by 43 users to make on average 289 payments a month.
Currently multiple Bally’s team members log into FreemarketFX’s portal to manually enter payments throughout the day, with this being the single highest volume payments initiator across the group. The effort currently requires the time of one FTE and is potentially subject to manual error due to the need to rekey payment information into the portal prior to approval for initiation.
The solution
The vision for this process is to automate the connection between Freemarket and Kyriba which is currently being implemented. Kyriba does provide several bank API connections already, although FreemarketFX is not on the vendor roadmap for the custom back-end efforts to connect as such. Therefore, Bally’s is leveraging its own Enterprise IT group to securely manage Amazon Web Services (AWS) resources to host custom ‘middleware’ code written by Actualize Consulting to broker the connection between Kyriba and FreemarketFX using self-service, open connectivity protocols.
Event-based serverless functions (microservices) hosted in the AWS cloud will manage the movement of data between Kyriba and FreemarketFX. For statement details, a scheduled trigger from Kyriba generates a list of bank account IDs resulting in an API request for those account’s statement details. The functions then transform that data into the CAMT.053 statement format and upload those statements into Kyriba.
Essentially, this will allow Kyriba to request statement information and receive it automatically in as long as it takes the data to move and transform. For payments, the generation of a PAIN.001 payment request message from Kyriba will immediately trigger an event, converting that message to the FreemarketFX format for initiation via API.
Payment status messages will be returned similarly via API or webhook to update the payment status in Kyriba using PAIN.002 PSR file formats.
Advanced logging and monitoring tools are being utilised to parse the AWS code-generated log information and allow individual error-codes to be pulled from the verbose log files. Bally’s Enterprise IT team will be able to define distinct notification behaviour for these different error metrics, depending on their relative importance and intended audience, without a need to modify the underlying code.
This solution will allow Bally’s to use Kyriba to report on balances and transactions for accounts held with Freemarket, as well as initiating the movement of funds out of those accounts with real-time payment status reporting.
Best practice and innovation
This is an example of where modern technology can be used to connect systems together by the end-user even where a specific bilateral connection has not been made available off-the-shelf by a vendor. The power of modern cloud platforms and APIs mean that serverless functions can be used to minimise infrastructure costs, free up employees for more strategic endeavours, and ensure integrations are tailored to the client’s specific need.
This problem will likely be seen more regularly due to the profusion of fintechs and their approach of often taking an ‘API-first’ view on connectivity. The ISO 20022 formats were selected to enable this effort to accelerate connections with other financial service providers if required.
Bally’s is essentially creating its own simple API as part of this effort, to receive payment status updates from FreemarketFX and send those on to the Kyriba platform.
Key benefits
As APIs proliferate, corporates will increasingly need to gain expertise in leveraging these directly to connect disparate systems that may not otherwise have an out-of-the-box bilateral connection readily available. This approach also serves to minimise the risk of being tied to an additional third-party Integration Platform as a Service (IPaaS) vendor to broker this API connection.
