Posted on by Payment Factory · 2 Comments

What is a payment factory?

Payment factory: Software for professionals

Version française

A payment factory is a software for professionals (ie software package) in the financial field, and more specifically the Treasury field, that enable the centralization of payments of a company. It can also be called “payment platform”.
The target and users of this type of IT solutions can even be reduced to a niche limited to treasurers working in large corporations and their colleagues. Indeed, these packages appear probably oversized for small businesses and to all organizations which do not have to face a multitude of flows and transactions each day.

By “large enterprises”, we mean most of the time large groups, that is to say multinational companies that have subsidiaries in many countries and even on different continents, and organize their cash as follows:

  • Local workflow: import or input of payments at the subsidiary and transmission to the bank
  • Local + central workflow: import or input payments at the subsidiary, then sent to the parent company whicc validates and sends to the bank
  • Central workflow: all operations are conducted at the parent company, including the creation of the payment and transmission to the bank

Centralization of Payments & Workflow

According to the internal procedures of the company, the number of steps to perform in the payment application before the bank transmission in order to centralize payments may vary.
Indeed, one can imagine:

  • manual input or import of payments in the software (from an upstream application) in a subsidiary
  • automated or manual payments constitution in batches according to criteria common to payments
  • these batches will be sent to a first supervisor who will validate or not the constitution of each batch (depending on the type and severity of the validation, a batch may be rejected if a single included payment is rejected or nevertheless be validated after the withdrawal of the offending payments)
  • this first supervisor will send to his manager these validated batches of payments; the manager will then digitally sign (via a token, key, or simply with a mouse click) the batches
  • a fifth protagonist will be notified by the software that batches can be sent to the central treasury located in the parent
  • within the parent company, a new workflow can then be set up within the payment factory and emulate some or all of the steps listed above
  • finally, a final head will send the payments batch(es) which have passed different validation steps described here to the bank, again via the software if the latter includes a bank communication module

Each of these users involved in the validation process is often warned by an email automatically sent by the system and / or directly into the software via a dashboard and / or screens dedicated to actions to which the user is assigned.

Some companies have a workflow approach, within a payment factory, completely opposed to the one which is described here. They prefer instead automate everything to the last or the penultimate step in the process, just before the sending to the bank, and so let the application pass batches to senior status (a status corresponds to a stage) almost without human interference.

Unitary Payments vs Payment Batches

As we have seen, the best payment factories offer not only the sending of mere unitary payments to the bank, but payment batches. Then payments are centralized and grouped into bactches. Indeed, for obvious reasons of productivity, when thousands of operations related to payments and receipts are processed into the software, batch processing saves valuable time.
The payment factory allows well through macros (programs automating recurrent tasks) to define what types of payments will be included in a batch. For example, one can imagine that a batch cans be made made either of:

  • all current day payments to be made to the same bank account
  • all payments made by a given entity to another entity
  • all salary transfers
  • all receipts and collections of the week related to a particular supplier
  • etc.

The user who will be allowed to validate may then be selected according to their specific knowledge of the characteristics of payments included in a specific type of batch.

It may be added that, in some payment factories, conversely, the level of details of the financial flows treated can go beyond payments and payments batches with eg:

  • invoices attached to payment
  • groups of batches of payments to send to the bank

Bank Communication and Payments

The payment factory is in charge of communicating payments and payment batches to the different banks set in the repository, of receiving the responses of these banks (acceptance, refusal, request information …) and other banking messages, then of transfering them to the initiator, that is to say the user of the payment factory who executed the Bank Communication.
Like the Internet protocols – http (s), (s) ftp, smtp, pop, imap … – there are different bank communication protocols. The most famous, secure, but also the most used are:

  • SWIFTNet: protocol for exchanging banking information globally, managed by the SWIFT (Society for Worldwide Interbank Financial Telecommunication) company
  • EBICS (Electronic Banking Internet Communication Standard): Communication protocol based on https chosen by the CFNOB (French banking committee of organization and standardization) to replace ETEBAC protocols (ETEBAC 3 and 5), deemed too slow and less secure, in the early 2010s

These protocols are now (2016) used en masse by all the major international groups as part of their payments and collections.

Payment Factory or Collection Factory?

The term “payment factory” is actually restrictive, since it covers only half of the activities of this class of software of centralization of payments. In fact, the “factory” addresses both the payments of the company, but also its receipts. So one should speak instead of “payment and collection factory” or “receipt and payment platform.”

Indeed, flows and payments processed in the payment factories cover a wide range of means of payment and accounting types relating to the field of the company’s business, its customers (B2C vs. B2B) and its strategic choices:

  • transfers (mass, HR and salaries, suppliers, internal …)
  • direct debits (such as the French TIP, which will soon be replaced by SDD – SEPA Direct Debit – but also non SEPA, especially for non-European contributions) and collections (subscribers, customers…)
  • netting market and cash operations
  • LCR
  • checks
  • …

User Rights and Privileges

A good payment factory has to centralize all payments, but not all payments or other financial information has to be viewed and allowed to users. The software then has an administration part and user settings are sharply fit to define the options and viewing rights of a user, such as:

  • access to software
  • the password complexity
  • the expiration of his credentials
  • viewing or not particular menus
  • viewing some operations
  • visualization of certain details in certain transactions (eg a person’s name or amount paid in a transfer)
  • a ban on access to certain data (eg if the user called Dupont has no access to the entity called X, and if X is concerned by a payment that Dupont is supposed to have the right to see, he can get denied visualization)
  • validation of certain transactions or certain changes
  • the belonging to a group of users with common rights and privileges
  • the right of administration
  • electronic signature
  • sending to the bank
  • creating macros
  • receiving bank messages
  • …

Repository Integrated to the Payment Factory

To achieve an efficient payment factory, the centralization of all payments has to be done. But it’s not enough and many data needs to be included into the software database. They are often recovered from an upstream software through an import-export engine that transcribes the data in formats requested by the payment platform. This is, inter alia, of:

  • entities (subsidiaries, transmitting or beneficiaries)
  • banks
  • accounts
  • country
  • currency
  • holidays
  • IBAN structures
  • BIC
  • types of transactions
  • signature ceilings or limits
  • types of payments
  • …

This data repository is then used in payments or in the parameters of the various stages of the workflow, which is specific to each type of transaction.

Technologies and Payment Factories in 2016

Some payment platforms still use client-server technology, thus requiring installations on each of the user stations, in addition to the server software and the database (VB, C ++, SQL Server for Windows).
Heavy and outdated for several years, these technologies have gradually been replaced by software vendors by Web technologies and languages ​​(Java J2EE, PHP, Python…) and associated to the strongest and most widespread application servers (Tomcat, WebSphere, WebLogic…) and DBMS (DataBase Management System: Oracle, DB2, MySQL, SQL Server…) on the market.

The software based on Web technologies have the advantage that they can be quickly deployed and do not require any installation on the user computers.
Indeed, a simple web browser (Microsoft IE or Edge, Google Chrome, Mozilla Firefox, Apple Safari…) is then sufficient to access and connect to the payment factory.

Payment Factories and Hybrid Packages

The payment factories can be integrated with software suites offering a wider range of tools dedicated to treasurers or traders, CFO and accounting managers.
The jobs being complex and links between the different responsibilities and tasks of treasurers being sometimes not obvious, these application ranges are rare. They aim at attaching the payment platform to the different specific solutions:

  • the “basic” cash management software (matching of forecasts and achievements, investment and credit value cards management, or even netting, cash reporting …)
  • bank-accounting reconciliation (automated matching of bank statements and accounting entries)
  • TMS (Treasury Management System) or smart TMS or TRM (Treasury and Risk Management) which, according to its own approach, enables the management of all aspects of the trading group since the creation strategy of the financial operations (Front Office) to the accounting (Back Office) via the control (Middle Office) and the management of associated risks

Typology of supply and pricing

There are three major types of payment factory offerings, which also apply to the whole range of group treasuries-oriented software:

  • purchase of licenses + support: the company acquires from the software vendor or distributor a number of licenses the right to install the in-house software (server in its own premises), and to create N users and / or administrators and / or types of financial flows, without time limit, and buys a renewable one-year maintenance (bug fixes, support …)
  • SaaS (Software as a Service) and PaaS (Platform as a Service): offers the most modern and simpler right to access the payment platform, which is installed on a shared server managed and maintained by the vendor or distributor without time limit. Monthly or quarterly payment most frequently, the amount of which is calculated on the volume and number of users.
  • hosted: simple access to the payment factory installed on a dedicated server, managed and maintained by the publisher or distributor, without time limit. Monthly or quarterly payment most frequently, the amount of which is calculated on the volume and number of users.

If the SaaS or PaaS (advanced version of SaaS, based on cloud computing) is today on the rise in many sectors, the Treasurers remain reluctant to host sensitive data (payment flows and information users ) out of their infrastructure and their CIOs.

Whatever the solution chosen, the payment factory will be set to change, and new versions, either major or minor, of the software will be offered ans sold as upgrades to policymakers by commercials or consultants of the software vendor.

Advertisement