This month’s question
“Fraud (external and internal) has been a hot topic lately. File uploads (vendor and payroll payments) to any bank’s platform involve downloading a file from an ERP, or some other accounting system, saving it, then uploading. When it is saved, in some cases the file can be modified. What best practices have you seen or do you suggest to eliminate or mitigate this common global risk?”
Thomas Stosberg, Senior Product Manager, Client Access, Global Transaction Banking, Deutsche Bank, responded:
An increasing number of corporate customers’ audit departments are finding it critical to further review the electronic banking workflow, as it can open the possibility for fraud. The general issue with these workflows is that before transaction files are uploaded into an electronic banking system, these files are copied from the ERP system to a directory to which treasury users have access. This carries the risk that a file is potentially stored for hours, before the actual upload by these users takes place. For payroll payments the situation is comparable, in case the source system is not an ERP system, but a dedicated HR software suite.
The most suitable way to avoid fraud is to fully automate the process – meaning to limit temporary storage of transaction files to just seconds with event-triggered batch processes. One prerequisite to achieve this automation is redesign of the authorisation process to include a ‘corporate seal’. The corporate seal can be defined as a non-personalised signature based on a Public Key Infrastructure (PKI) server setup, eg re-using the functionality of communication protocols based on the Secure Sockets Layer/Transport Layer Security (eg used in https, FTPS, AS2) or a comparable security component, which also includes an automated hash value comparison. This means there is no further authorisation in a bank system needed. With the inclusion of a corporate seal it is possible to directly transfer the transaction file to the bank, eliminating the time window for a potential intruder to change the contents of the file.
Another way to add further security to the processing is to utilise an additional encryption of the payroll file, which is on top of the transport layer encryption used on the communication layer between corporate and bank. As a result, the creating system encrypts the file and on each processing step (also for a longer temporary storage window) the file is only accessible in encrypted format, so that there is an additional hurdle to overcome for manipulating the files. In such cases it is also advisable to have a clear segregation of duties for those processing steps so that internal users can only access the files in one of those steps.
From a technology point of view, ERP/HR vendors are working on solutions to evade storing of files at all or alternatively avoid the creation of files, but rather move storage of data to a dedicated database system. One example of such a technology is streaming – this means the HR system creates a data stream with transactions, which is directly transferred to the bank. This approach is comparable to the technology used for telecommunication. There is however only very limited usage so far with these options.
In summary, the best solution for avoidance of fraud and addressing all related audit issues is the full automation of process. This automation is already the best practice approach for payment factory projects based on host-to-host or SWIFT communication. At the same time, this automation addresses most critical questions for external regulatory requirements such as the Sarbanes-Oxley Act. For scenarios in which automation cannot fully achieved, an additional application encryption with tools such as Pretty Good Privacy lowers the fraud risk, as it makes it harder to manipulate data, especially as there is limited time available for intruders to proceed. Going forward, the usage of new technologies will give further security levels, however corporates will need to continue to revisit workflows and change their operations accordingly, especially concerning the authorisation process.
Paul Higdon, Chief Technology Officer, IT2 Treasury Solutions, responded:
The security of file uploads to banks is a classic example of an area that raises process and governance concerns, and where best practices have emerged to mitigate risk. Fortunately, this is an issue that is specifically addressed in almost every treasury design or re-engineering project. So, how can a corporate treasury secure payments processes whilst in ‘transit’ between a corporate financial system – often a treasury management system (TMS) and the final recipient?
A clear hierarchy of best practices has emerged. In general, well defined and enforced processes for reconciliation, management oversight of transactions and decision-making should be the starting point for the design of a financial organisation’s payments governance. Key questions – who needs to verify a transaction? What controls are required? – are management, rather than technology issues and should be reflected in the design of a secure treasury process (see graph). Automated, airtight and tamper proof treasury technologies between defined and auditable user interventions, authorisation and reconciliation, are therefore enablers of best practice processes.
The maximum level of controlled automation and streamlining – and hence best practice – is now clearly represented by processes that provide a single, secured link to multiple banks. SWIFTNet and – within a corporate financial environment – seamless SWIFTNet Linked (SNL) treasury systems (labelled SWIFTReady) represent the best-known example, although regional alternatives exist. These confine the internal ‘drop’ of payment files onto a network drive to a proprietary, controlled environment and otherwise exclude the opportunity for payment files to ‘sit’ or flow unencrypted where they can be accessed. In process terms, the stages between authorisation and reconciliation are eliminated; user access is controlled by state of the art technologies.
Where this is not yet in place, the latest generation of banks’ proprietary internet-based platforms provide for a secure process that can be integrated within a treasury system. Both SWIFT and bank systems enable a treasury team to connect directly to the bank platform and to upload data without the need for a separate data file to be created and uploaded on to an external network drive or FTP site. This point-to-point transmission enabled by these systems is tamper resistant and fully automated: seamless, secure, and requiring no user intervention. An identical technology is also used when connecting to dealing portals such as FXall and 360T.
In the absence of such a bank platform or SWIFTNet Linked financial system, what then? Some banks, offer the use of a secure – encrypted – FTP (SFTP) service for the transfer of payment files. If this is available, an automated treasury system should write the file straight on to the FTP site instead of a local network drive, engineering out an opportunity for manual interference.
As a final option, however, where the above are not possible, automation may mean simply that a file is placed onto a network drive automatically – typically as part of a system process or job. In this case, access to that drive should be strictly limited to the treasury management system (TMS) and the application to which it is being routed, such as a bank payment system, preventing a user from editing the file before it is processed by the bank.
A secure process should also include robust verification: errors are as much of a threat and headache as rogue users. Reconciliation workflows should be automated where possible – and segregated.
The next question
“What is the treasury recruitment market looking like at the moment? Has the Eurozone crisis affected the number of opportunities available? Also, how have salaries been affected by the turmoil?”
Please send your comments and responses to QA@treasurytoday.com.