Payments Processing Models

The needs of our customers concerning payment order processing are very different, which is why we are linked to various solutions offered by our partners.

 

Find more about our partners here...

 

While the operational payments generally originate in the company's accounting, Trinity TMS generates transfers from cash management or treasury only. The entirety of the payment flows as the basis for the cash forecast is found in the treasury system anyway; effective payments arise in Trinity TMS as a result of daily planning or in isolated cases from financial transactions. The route and file format of such payments is defined by the creation of so-called standing settlement instructions (SSI) in accordance with the dual control principle in order to eliminate attempts at fraud.

 

Operational payments to suppliers, employees, authorities and the turnover information on incoming and outgoing amounts take up a much larger space in most companies compared to the financial cash flows, which is why the digitalisation and optimisation of company-wide payment transactions often plays a major role. The ongoing upheavals in the transmission paths under consideration (EBICS, SWIFT, host-to-host, API) and file formats (replacement of national European formats by SEPA and of SWIFT MT by ISO 20022 XML), legal rulings and the appearance of payment service providers are causing a lot of movement in this area.

 

Together with our clients, we discuss the wishes, requirements and prerequisites and can then make a recommendation of suitable solutions and implementation partners.

 

Decisive for an assessment of the optimisation possibilities are

  • the distribution of payment accounts in different countries and continents,
  • the type and number of transactions (account information and payments) and
  • the customer's wish to centralise and - if necessary, additionally - to
  • optimise the processes (payment factory).

The following gradations can be roughly distinguished:

 

Scenario 1: Your company only operates in Germany (and possibly Austria, Switzerland and France).

 

here, an up-to-date EBICS connection to the banks, which can be established by electronic banking specialists of your house bank, is sufficient in most cases for the collection of account information and typical payment transactions. We are happy to assist you in determining suitable banks and specialists or recommend the bank-independent solution MultiCash@Web from our partner Omikron Systemhaus.

 

Scenario 2: The company from scenario 1 has other accounts in other countries and only wants to be informed about the current balances and turnover there. Payment transactions should continue to be processed locally.

 

This can also be done via an EBICS connection only. To obtain the additional statement information, one asks one's major bank with a SWIFT connection to request the statements for the respective accounts from the foreign bank and to provide them together with the domestic account information for retrieval via EBICS.

 

Scenario 3: The company from scenario 2 would now like to be able to transfer the local funds of the foreign accounts at irregular intervals to a central account after all, as these are e.g. solely accounts of distribution units and hiring a person to look after the account locally would not be economical.

 

Even in this case, you can still continue to work with an EBICS connection by creating a "Request for Transfer" order (SWIFT MT101) and feeding it into the global SWIFT network via your house bank using EBICS. The "request for transfer" is thus transmitted by your domestic bank via SWIFT to the foreign bank, which triggers a transfer debiting your foreign account to your domestic account.

 

Of course, all this requires some contractual arrangements (SWIFT MT101 Agreements between you and the banks involved as well as between the banks and SWIFT among themselves) and cannot be used without preparation. Please note: MT101s are only suitable for single payment orders and SWIFT's traditional message types are planned to be replaced by ISO20022 XML files by 2025.

 

Scenario 4: If the company from scenario 3. develops splendidly and receives large deposits in the foreign accounts every day, then it may be worthwhile to use cross-border cash pooling. However, this step depends not only on the associated costs of the banking service, but also on legal and tax regulations and should be considered carefully for each transaction channel on a case-by-case basis before realisation. Also, not all credit institutions offer the same services in the different countries.

 

Nevertheless: Up to this point, companies still do not need their own SWIFT connection, but can realise effective and comparatively inexpensive cash management via EBICS with their banks which are suitable for the desired services.

Scenario 5: If there are very many foreign accounts and banks and these are to continue to be used and centrally managed after a review of the necessity, a concept that goes beyond EBICS becomes more and more likely. In order to find the optimal solution here, a good analysis of the existing landscape and prioritisation of future requirements is essential in advance. By taking stock of which accounts are held at which banks for what purpose, what kind of payments (e.g. single/mass payments, urgent transactions, credit transfers, direct debits, cheques, salary and tax payments) run through them, right up to the resources needed to operate the current account structure, the current situation becomes clearer.

Already during the collection of information, many peculiarities stand out, which quite often lead to rejecting the idea of centralisation for certain countries. In any case, the status quo helps to set priorities when adding to the types of payments also their volume and transaction numbers, as there is a different solution for a payment of more than 10 million USD per year than for 100,000 payments of an average of 100 USD to 20,000 recipients.

 

In this case, too, not every bank offers the same services in all countries. In addition, there is now the possibility for companies to connect directly to the SWIFT network in order to feed in payment orders, receive account information and use other services. In order to be able to work here in a commercially viable way, the company first needs a licence and its own address (SWIFT BIC), as well as its own know-how, patience in contract negotiations and transaction volumes that are in suitable proportion to the future running costs. Alternatively, the company can also call in specialists to help it get started as a SWIFT Service Bureau or intermediary agent with ready-made interfaces, format standards and already active contracts. We are happy to provide advice and support in selecting the solution that is most suitable for your company.

 

We connect Trinity TMS to your existing electronic banking system or, together with our partners (e.g. Omikron, Broadridge, TIS, EFiS, Serrala), find the right new solution for you, if desired with features for format conversions, bank charge control, sanctions list check, eBAM and fraud prevention or even a payment factory.

 

 

You can find more about our partners here...

Case Study

Ceconomy

Callback


    *The data sent will only be processed for the purpose of handling your request. You will find further information in our Privacy Policy