Merck & Co.'s revolutionary payments automation project is part of corporate-wide initiative in which senior management decided that instead of running a respectable technology shop, it was time for Merck to sprint to the head of the pack. Part of the initiative involves installing a single SAP system for all of Merck worldwide, replacing mostly JDEdwards ERP installations and some other software. However, the treasury project will not wait the two or three years it will take to complete the SAP installation, says Hans-Maarten van den Nouland, director of international treasury services, so it will be implemented on the JDEdwards systems until then. Van den Nouland says the new solution will also be carried on the Wall Street Suite, which Merck already uses across the globe.

The point of the project, says van den Nouland, is to get Merck out of the interfacing business entirely. Payment files will be initiated from the ERP A/P system. They will be digitally signed when an encrypted copy of the transaction is sent to an external database for future reference. The original payment transaction file will flow to Wall Street Suite 7.1 (formerly Trema Finance Kit), which will check to see that treasury policies were followed and route the payment from the appropriate bank account. From there, files move through SWIFTNet SCORE to Citi and HSBC. The banks will be expected to pick up the files, open them and confirm that the transmission has not been tampered with; they will then compare the initiator with the authorization file. If the transmission is dirty or an initiator is not authorized, the payment stops. If it clears the security hurdles, the banks will take the generic SWIFT message and map the payments to the appropriate clearing systems, according to Merck's rules, which normally require using the least expensive route.

The single file goes as a FileAct wrapped file in a version of the up-and-coming ISO 20022 format. However, Merck is not fully in agreement with ISO 20022′s proposed XOR logic, which "would force us back to deciding, case by case, whether a transaction required an IBAN or a BBAN," van den Nouland says. "We don't ever want to go back to applying logic at the transaction level. We want to transfer all that to our banks and think the ISO group should allow a bank to play that role."