Based upon data stored in the vendor master file, the payment instrument to be used will be determined. When the initiative is with the payer, a choice can be made between

• Electronic payment
• Cheque payment
• Card payment

When the initiative is with the payee, the invoice can be settled through a direct debit.

Cancellations

A company might want to cancel a payment or group of payments issued to its bank earlier. The company can send a cancel-payment-request. The bank will verify whether it is allowed to cancel the payment (e.g. payment is not irrevocable, which would require the consent of the payee, and payment has not yet been issued to the next bank or ACH in the chain). If the payment can be cancelled, the bank will send an accept-cancel-payment message. If the payment cannot be cancelled anymore, the bank will send a reject-cancel-payment-message.

The current market practice is that changes to a payment that was already sent to the bank are handled through a cancellation of the original payment and a reissue of the revised payment. When payments are submitted to the bank earlier and are warehoused at the bank awaiting further processing, another option could arise to accept amendment of warehoused payments rather than cancellations/reissues. The business rules when to accept amendments (at what stage of processing and for which data elements) will need to be detailed further at a later stage. The key messages are:

• Request-cancel-payment
• Accept-cancel-payment
• Reject-cancel-payment

Cancellations can be made on a batch level or individual transaction level. It is required that the unique id of the batch or payment is included in the cancellation request. Further details of the original payment may be added optionally to validate that the correct payment-id was used.

Like with the status message, driven by the business rules (service level and legal issues), the bank can either accept or reject the cancellation. The structure to report this is similar to the status message which does not refer to the payment transaction id but to the cancellation-id.

Service Level Management

Corporates may agree with their banks to apply certain service levels. This could relate to

• Preferred ways of processing,
• The timing, level of detail and other decision elements (all, only negative, specific rules) of status updates
• Arrangements with respect to direct debit contracts and validations
• Handling of specific situations such as rejected transactions
• Authentication and authorisation processes
• Security and communication protocols to be applied
• Financing arrangements

TWIST considers it useful to structure these service level agreements by using standardized messages. This topic needs to be addressed in more detail at a later stage.

Claims and Investigations

When the actual payments reported to the company do not reconcile to the expectations, investigations will be made. The trigger and actions for the investigations process differ per type of payment.

For commercial payments, a discrepancy between the expectation based on a remittance advice and the actual funds received based on the bank statement will lead to inquiries by the accounts receivable department with the payer (company) or the bank, depending on where the issue seems to have occurred.

In case of treasury payments, the expectation is driven by the contract that requires settlement on a specified due date. If the money does not arrive, the counterparty will be contacted to find out whether the amount has already been submitted or not. If it has been submitted, either or both parties can put in an investigation request at their bank to figure out what happened to the payment.

If it turns out from the investigation that the payment was not processed correctly (e.g. on time) by the bank, the corporate can put in a claim to request compensation for the interest due to applying incorrect value dates.

Claims and investigations can be submitted to the other party using the ‘status request’ and ‘status response’ messages. As a next step, some additional data fields might be added to reflect the reason for claiming and the nature of the claims (e.g. value date difference).

INTERBANK PROCESSES

TWIST does not aim to describe the messages that are used between banks or between banks and clearing houses. For cross-border interbank payments, standard SWIFT messages have been available for a long time and are updated frequently. Most national ACHs have their own bespoke message format. However, a convergence is seen that the ACH message formats are almost similar to the SWIFT MT103 interbank message.

What TWIST aims to achieve is that the currently available standard message formats are synchronized with the message format as designed by TWIST and are discussed with other standards organisations like SWIFT with the objective to come to universal payment standards.

TWIST aims to issue an addendum to map the resulting payment messages to the most relevant ACH formats. This will indicate to what extent such a message can be applied without major restrictions using specific ACHs. It will also create an opportunity for banks and ACHs to agree on specific implementation rules to ensure that the key requirements are met to at least deliver the unique transaction reference through the interbank- and ACH-messages.

BANK TO CORPORATE PROCESSES

The bank of the account to be debited (instructed thereto directly by the corporate or through an intermediary service provider or bank) will need to process the payment instructions received. This bank will perform several activities:

• Authenticate the payment instruction file received (at file level)
• Technical validation of contents (at transaction/data field level)
• Business validation of contents (debit and credit side)
• Determine payment routing
• Send out payment
• Post payment
• Report (bank statement and/or status info such as debit and credit advice)
• Forward remittance details (optional)

The validations might lead to the rejection of payment instructions or the repair of payment instructions, triggered by the bank. The same might happen in the next step of the interbank chain at ACH level or beneficiary bank level. For rejections, the bank must inform the corporate that the payment could not be processed and trigger further action. For repairs, it is recommended that the bank informs the corporate which allows the corporate to make adjustments to its payment process/applications to prevent similar errors from occurring in the future.

Payment Status Information

A company may be interested to track the processing of a payment. There will at least be interaction between the company and its own bank with respect to the payment status. To what extent it is possible to verify processing down the chain (clearing house, beneficiary bank) might be interesting, but whether this data can be delivered in many cases is questionable. The following messages can be used:

• Payment-status-request
• Payment-status-response

The payment-status-response message will also be used for rejections and repairs. In those cases, some additional fields will be populated.

A company can (ad hoc) decide to request its bank to provide information on the status of a specific payment. Therefore, the company will send a request to its bank. The bank needs to receive a payment-id to be able to track the payment. To achieve the best possible result, the request is modelled to optionally hold multiple id-s for the same payment, i.e. the payment-id that originally was used by the corporate as well as the bank’s payment-id that was used for submitting the payment into the banking channel. If the bank’s payment-id is used, it is more likely that status information beyond the bank’s own administration can be found as the next bank of ACH in the chain is more likely to know the bank’s payment-id than the original corporate-payment-id.

The ability to deliver the statuses as described in this document to some extent depends on the quality of the interbank and bank-ACH interactions. The more complex statuses are those at the end of the payment chain which requires active feedback from the ACH and/or the receiving bank.

A bank will receive the payment-status-request (or process a standing order to provide information on the status of a specific payment), collect the data requested and compose a message to be sent to the corporate to update them on the status of the payment.

Besides data that link the response to the original request, the message will indicate the actual status of the payment (what statuses are available depends on the ability of the bank to deliver) and a timestamp, such that the corporate has an indication at what time this status was reached.

Rejections

After a company has sent a payment datafile to its bank, the bank will check whether the file can be processed. Therefore, multiple validations are used consecutively.

First, the technical integrity of the payment datafile will be checked. This will include validations on the digital signature of the corporate, the header data and a file-total/checksum. If either of these validations turns up with a negative result, the total payment file will be rejected.

The payments will be validated on a technical/format level to verify that the payments can be automatically processed. Typical problems are: mandatory fields are missing, data fields do not comply to the standard format, data fields have incorrect values. A bank might try to repair the data fields that can not be validated. If repair is impossible, the payment will be rejected.

As soon as the payment datafile has been validated on a technical/format level, the bank will check whether the balance or available credit line of the account to be debited is sufficient for processing the payment. If the balance is insufficient, the bank and the corporate will have agreed on a procedure what reaction is required (options are: reject and return the datafile, hold the file and try again after a certain time, hold the file until new funds have come into the account, split the file into individual payments that can be processed and payments that are held for further action).

If the balance check was positive, the bank will process the credit entries to be made. The individual data fields will be validated against business rules. If the data fields are technically sound, it still can be that business reasons make it impossible to process the payment. These reasons typically apply to accounts that are blocked for processing (account closed, accountholder deceased, account blocked for entries). In those cases, the payment can not be processed and will be rejected. This type of business validation can occur at the payer’s bank but also further down the chain at the ACH or the payee’s bank.

A payment-rejection-code is added to the status information message to inform the corporate of the reason that the payment was rejected.

The following groups of rejection codes can be used:

• File rejections
• Invalid header data
• Invalid checksum/control total
• Available funds rejections (including agreed upon reaction)
• Insufficient funds, payment rejected
• Insufficient funds, payment held for retry
• Insufficient funds, payment held until incoming funds
• Data format rejections
• Data field in error
• Mandatory data field missing
• Data format error
• Invalid data
• Incorrect value date (too early or too late)
• Business rejections
• Beneficiary account not accessible
• Account not valid
• Account closed
• Account blocked
• Invalid account details
• Direct debit mandate rejected
• No mandate available
• Mandate expired
• Mandate limit excess
• Payment reversed by payer

Several banks have mentioned that for security reasons, any rejection based on security related validations (e.g. digital signature rejected) will lead to a manual process rather than an automated process to limit the risk of fraud.

The payment-rejection-code received by the company will trigger the next action. If the data can not be processed due to technical or format errors, the entire file or the individual payment can be corrected and sent again.

If the data has a correct format, but is not correct, the company needs to verify the correct value of the data and send in the corrected payment again.

If the data are correct, but the company does not have a sufficient available balance, the company can agree with its bank what the next action will be. A rejection will trigger the company to issue the payment again as soon as sufficient funds have been made available. Another option is to warehouse the payment at the bank for some time until new funds have come in, either from normal payment transactions or by specifically arranged funds in the account. This will save the company the trouble of resending payments. There will be a time limit until the payments will be rejected anyway.

Repairs

If the bank receives a payment datafile from a corporate which contains data fields that have format problems, the bank may decide to try to repair the invalid data fields. This process can be automatic or manual, sometimes in (telephone) consultation with the client. If the correct value can be determined without jeopardizing the integrity of the data file, the bank will repair the payment data (e.g. a bank branch code is used that has become obsolete and has been replaced by another code). Given the effort that the bank has to make in such a case, the bank may wish to charge for that effort.

In some cases, it could be that the corporate’s static data file contains incorrect values, which might lead to new payments to be repaired in the future, thus causing unnecessary effort to the bank and unnecessary charges to the corpora

Therefore, data fields are included in the status information message to inform the corporate on data fields that were repaired by the bank, which can trigger the corporate to update its static data.

Bank Reporting (bank statement, debit and credit advices)

The bank will inform the account holder about movements on the account. Banks and its customers can agree to send intraday information on individual transactions (may depend on type of transaction) by using debit and credit advices.

The bank statement will supply current balance, previous balance and information on movements. The bank statement will specify the payments (both debit and credit postings) that the bank has processed. Depending on bank and options available to the customer, the bank statement will specify individual items or aggregated amounts (with link to a batch/group-id, e.g. per payment method). Individual items will be accompanied by limited details to enable reconciliation (such as: unique transaction reference, counter-account, counterparty name).

Per transaction, a book date (date on which the transaction was posted to the account), a value date (date as of which the transaction impacted the balance of the account for interest calculations) and the available date (date as of which the amount is owned by the account holder) are reported.

For debit postings (payments issued by the payer), a choice can be made (as mentioned in the payment message) to post the individual payments to the bank statement or the only post an aggregate total at the level agreed (group/batch). As the company is aware which payment instructions have been sent to the bank, it is a fair expectation that most payments will be carried out as instructed. Rejections and returns can be considered exceptions. Therefore, in many cases, the aggregate debit posting option is used and sometimes even forced by the ACH.

When sending the payment instructions to the bank, the corporate can make a posting from ‘accounts payable’ (debit) to ‘payments in process’ (credit); other corporates may decide to directly post from ‘accounts payable’ to the ‘bank’ account.

The bank statement will confirm the total amount which will trigger the posting: ‘payments in process’ (debit) to ‘bank balance’ (credit). Any rejected payments will be reported separately (itemized) and will lead to the posting: ‘payments in process’ (debit) to ‘accounts payable’ (credit, reopened).

For credit postings, the data on the bank statement can be used to reconcile received payments with remittance advices or open invoices. The remittance details can be used to reconcile the accounts receivable.

In order to facilitate a straight through reconciliation process, the bank statement using itemized payments should contain the unique transaction reference as included in the payment message. In cases where the interbank or bank to ACH messages do not allow for a specific data field to hold the unique transaction reference, the bank is required to find a solution to transmit the unique transaction reference to the beneficiary bank and report that on the bank statement as if it was derived from a standardized data field. This unique reference is part of the remittance advice as well and can thus be used to reconcile the payment on the bank statement to the remittance advice. For proper reconciliation, any bank charges should not be deducted from the original payment amount, but be mentioned separately on the bank account statement.

Within the corporates processes, the remittance advice can be used to reconcile accounts payable/receivable invoices to remittances. The bank account statement can be used to reconcile the (sum of) remittance advices to the actual payments. The following postings can be applied:

Remittance advice: Debit payments to be received. Credit accounts receivable

Bank statement: Debit bank. Credit payments to be received

Any movements in the bank balance that are not related to a commercial payment or treasury payment should be reported separately with specific (standardized) references on the bank statement. Examples are: bank charges, balance regulation transactions such as zero or trigger balancing where amounts are moved from one account of the corporate to another (master)account of the corporate.

ACH PROCESSES

An alternative solution would be that payments are not sent to the debit bank, but rather directly to a banking service provider (BSP)_such as an ACH or a card company. The advantage of this model is that these service providers already perform a central role in the settlement process and reduces the need for a large number of banks to adapt their infrastructure. This might bring an earlier adoption of the standards. The process flow differs from the one where the payment is sent to the debit bank. Now the payment is sent to the BSP. The BSP has to verify with the debit bank that the account to be debited has a sufficient balance. After approval, the payment will be settled with the credit bank. This process is shown in the diagram below.

DIRECT DEBIT PROCESSES

A direct debit is a transaction sent by the supplier to the bank of the payee or to an ACH with the purpose to debit the bank account of the payer and credit the bank account of the payee. The legal requirements with respect to direct debits vary from country to country and will be contained in a set of scheme rules to which a group of banks, or countries, agree to be bound. These rules will include the redress available to payers if they want to revoke a direct debit instruction, or if it has been debited incorrectly.

In most cases, a specific contract should be agreed between the payee and the bank that the payee is allowed to issue direct debit transactions. Banks will often restrict such contracts to certain customers or for specific purposes e.g. the collection of utility bills.

A mandate should be agreed between payee and payer (either as a standing instruction or as a one time instruction) in which the payer as the holder of the account to be debited confirms to agree that his account may be debited by the payee for a specific type of service. This mandate may have to be transmitted to, and processed by, the paying bank before debit transactions can be sent. Based on this agreement, the payee will send a direct debit transaction to the bank or ACH to have the payment processed.

Direct debits can be divided into pre-authorised and non-pre-authorised direct debits. With a pre-authorised direct debit, the mandate is agreed upon earlier and known by the bank. With a non-pre-authorised direct debit, the direct debit transaction includes a request to have the payer authorize the direct debiting of his account.

Given the different nature of this process, the process of confirmations, rejections and revocations is more complex than with payments issued by the payer. In most countries, the payer is allowed to revoke the direct debit within a certain amount of time after the payment is debited to his account.

The direct debit message is often used by companies with a high volume of invoices to various debtors (e.g. utility companies, telephone companies). The key difference is that the initiative to start the payment process is taken by the payee/beneficiary rather than the payer.

The direct debit message therefore closely resembles the payment message, with an addition of a link to the agreement concluded previously. However, unlike normal credit payments, direct debits can usually only be processed between banks where a specific direct debit scheme applies.

The following picture represents the process of issuing a direct debit transaction, assuming (if applicable) the mandates have been properly set up. The step to request and receive authorisation of the direct debit transaction through the debit bank and the debtor refers to non-preauthorised direct debits or the first direct debit in a flow of (to be) pre-authorised direct debits. After confirmation of authorisation, the credit bank will post the credit before the actual settlement. If settlement would fail later, the credit is reversed.

The boxed represent actions and the circles represent messages. The orange coloured messages are TWIST messages and the pink messages are existing interbank messages.

Business Issues

There are a few key business issues surrounding the processing of direct debits.

An issue, which is comparable to the payments issue, is the unique identification of transactions through the entire processing chain. A problem in practice is that rejections and even more common returns and revocations of direct debits do not reference the original transaction thus causing a lot of manual work.

Including a unique identification for the direct debit transaction which is carried throughout the processing chain will be a major improvement.

Some processes surrounding direct debits might in many cases still be manual (such as revocations). Creating messages to structure these interactions can support the level of automation.

A major issue around direct debits, at least in Europe, is that a direct debit is primarily a local / domestic product with specific legal implications. Task forces in Europe are looking to create a Pan European Direct Debit product which not only harmonises the processing but more importantly harmonises the legal characteristics of this product. This legal harmonisation will take a considerable amount of time.

The differences in processes and interactions are far less important than the legal issues, so there are certainly opportunities for harmonised processes and messages to resolve some of the operational issues before the legal issue can be resolved.

For corporates, it would be beneficial to be able to send direct debit transactions to a single bank or ACH, irrespective of country and data format, for all accounts involved, rather than having to use several (currently more than 20) data formats for existing domestic products.

Direct Debit Revocation or Reversal

Although a direct debit is in most cases a pre-approved payment instruction, depending on the legal situation, the payer may have the right to instruct its bank to revoke the payment within a specified amount of time (may range from hours to a considerable number of days). The payer will send a direct debit revocation request. Its bank will check whether the request was issued within the time frame required given the specific direct debit product. If the request was on time, the payer’s bank will reverse the debit entry and the beneficiary’s/payee’s bank will receive an instruction to reverse the credit as well with reference to the original transaction number.

Another option is that the debtor/payer requests the payee to reverse the direct debit. The difference is that the process is initiated by the payee.

The process of revocation/reversal is the same in both cases, reference should be made to the uniquely identified direct debit transaction. Any postings made will be reversed at the banks involved and communicated with the debtor/creditor (payer/payee) through debit/credit advices and bank statements.

CHEQUE PROCESSES

TWIST has recognized that the choice to make a payment using a cheque can reuse a considerable part of the data elements also used for electronic payments. Some additional data is required.

This section of the site contains an overview of the different kinds of cheques identified. For every cheque-type, TWIST has tried to identify the characteristics and the specific information exchanged between a corporate and its bank in all phases of the settlement process.

In addition to the cheque processing from a Corporate point of view, the more detailed cheque processes, technical characteristics and applicable standards are described. The multitude of national standards for cheques is a serious bottleneck for using cheques in international trade and payment processes.

Cheques are by design “non-STP”, meaning that they require manual processes. Although initiatives have started to avoid some of these manual processes (truncation: conversion of the physical cheque paper into an electronic image: “Cheque 21”, “Accounts Receivable Conversion”; automated reconciliation in both bank and corporate inbound processes), or to outsource some of these processes to service providers (cheque printing by ASP’s, Lock Box Services), cheques remain an inefficient payment process. Many corporates try to move away from cheques and apply electronic funds transfer wherever possible. But cheques will be around for a long time for the following reasons:

• Insufficient bank account details to initiate an electronic transaction
• Insufficient infrastructure to initiate an electronic transaction when immediate payment is required
• Insufficient country infrastructure
• Legal
• Absence of political drive to move cheques out of the system
• Pricing of the cheque as product (free in some countries)
• Volume
• Payment behaviour.

Types of Cheques

For this analysis we have identified the following types of cheques:

• Customer cheque , (also called Corporate cheque) drawn on the bank account of the customer , debited on his account when the cheque is cashed . The cheque can be written or printed by the customer, a service provider (ASP), or the ordered bank providing the printing service as ASP.
• Certified customer cheque, drawn on the bank account of the customer , debited on the customer’s account when the cheque is cashed . The bank prints and certifies the cheque, guaranteeing payment.
• Bill of Exchange, issued by the customer, drawn on the bank account of the customer , with a future value date (do not pay before…) and an expiry date (do not pay after). Debited when the cheque is cashed.
• Bank cheque, (also called cashier’s cheque) drawn on the bank’s account . These cheques will be printed by the ordered bank. The bank guarantees payment. The following sub-types are recognised for Bank cheques:
• Guaranteed bank cheque, debited on the customer’s account when the cheque is issued.
• Clean Draft, a guaranteed bank cheque with a future value date (do not pay before…), which in commercial terms is a “negotiable instrument”: the beneficiary can receive early payment from any bank under subtraction of a discount. The ordering customer’s account is debited on value date.
• Letter of Credit, a guaranteed bank cheque with a future value date (do not pay before…), with an additional condition for payment: the bank must have received proof (documents) of correct delivery of the goods. Debited when the cheque is cashed. Note: other L/C models may exist with different roles for the banks involved.
• Beneficiary Bank cheque, printed by the beneficiary’s bank in order to execute an electronic funds transfer order, where the bank account of the beneficiary is unknown. The cheque will be drawn on the bank account of the beneficiary’s bank . The account of the ordering party will be debited at issuance of the payment order.

Summary Table of Cheques and Characteristics

Cashing the Cheque

Apart from the above characteristics, the cheque may be payable in cash or “crossed”, making the cheque only payable by crediting the beneficiary’s bank account.

A cheque may also be transferable “payable to bearer” or non-transferable, i.e. only payable to the named beneficiary “ordered”.

With the “ positive pay ”procedure (especially common in the US), the issuing bank verifies whether a cheque is payable before actually being paid. The issuing bank maintains a register of issued cheques, either based on cheques printed by the bank, or information received from the customer or the ASP (a so-called issuance file). Information about the cheque presented is forwarded via the Federal Reserve Bank to the issuing bank for verification. This process allows the requestor of the cheque to issue a “stop payment” and prevents fraud (copy of cheque, change in amounts, etc.). After presentment of the cheque, the beneficiary will have to wait 2 days before the cheque is actually paid.

Positive pay can be applied both with Customer cheques and with Guaranteed Bank cheques.

Stop Payments of Reversal

After the issuance of a cheque, reasons can emerge to cancel the payment instruction (like bankruptcy of the beneficiary, failure of the beneficiary to accomplish his obligations, fraud, etc.). The way to cancel a cheque is to issue a “stop payment ” instruction.

In case of “positive pay” banks always verify if a stop payment has been issued, or even allow the ordering customer to decide not to pay by issuing a “stop payment” after presentment.

For domestic cheques payment to the beneficiary is executed “ under usual reserve ”(UUR): the bank can reverse the payment within 3 days (may differ per country) if the ordering customer has issued a “stop payment” or the ordering customer’s account cannot be debited.

After this “under usual reserve” period, the risk is for the paying bank if a payment can not be reversed. In case of fraud reversal will always be tried.

Another condition may be “after final payment”(AFP), which means that the beneficiary is not paid until the deposit-bank received the money.

For cross-border cheques it is usual to verify if a “stop payment” has been issued or even apply the AFP condition before paying the beneficiary.

Dates for Cheques

When instructing an ASP or the bank to print a cheque, the following dates are relevant:

• The requested print date, the general “requested execution date” on the payment order.
• The future value date, also called the maturity date: “do not pay before”.
• The expiry date: “do not pay after” or “void after”. (only applicable for Bill of exchange).

Remittance Details

A “stub” (the upper 2/3 rd of the letter or A4-form) may be attached to the cheque, containing the payment details as a “remittance advice”. The “stub” will be used for the operational reconciliation by the Accounts Receivable department, while the cheque part is used for the financial settlement process.

When the cheque has to be printed by the bank or ASP inclusive of the “stub”, all payment details have to be included in the payment order in structured format, including discounts applied and other invoice-adjustments (if applicable and allowed).

CARD PROCESSES

TWIST has recognized that processes around card payments (especially the authorisation request and response) are already highly standardized using an ISO standard. Therefore, TWIST could not add to redesign of the processes.

The basic process relates to the so called ‘four corner’ model between merchant, acquiring bank, issuing bank and card holder. The card holder wants to enter into a transaction at the merchant (website, point of sale). The merchant will send a request to the issuing bank to verify the authenticity and credit status of the card holder. When approved, the transaction will be carried out and settlement will take place through from the issuing bank to the acquiring bank who wil credit the merchant’s account.

What TWIST has designed is to include a message for settlement of card payments based on the generic payment message and adding specific data elements required for settling card payments (such as obviously the card number and expiration date). For further details on the card payment settlement message, please refer to the section on card messages.

WORKING CAPITAL FINANCE PROCESS

• WCF Business Proposition
• WCF Process Overview

TWIST has identified that future payments might be used to negotiate financing through early payment, in which case a discount will be applied to the original amount as a premium for early payment. The early payment can be negotiated with the payer or with any bank or factoring company.

To facilitate this process, some specific messages can be used. TWIST has identified the following messages:

1. TWIST financing request
2. TWIST financing offer
3. TWIST financing acceptance

Depending on the timing of the negotiations and the parties involved, some specific financing elements can travel with the payment.

The TWIST working capital financing messages will be develop in more detail during the second half of 2005.

The data fields that can be included in the payment message with respect to working capital financing arrangements are:

The discount percentage or amount can be added into the message when sent from corporate to bank in the case where the payer agrees with the beneficiary to submit the payment early and is allowed to discount the amount.

In the case where the bank offers early payment at a discount to the beneficiary, these data elements will not be present in the initial message from corporate to bank but will be added at a later stage.

WCF BUSINESS PROPOSITION

TWIST recognizes that information on future payments can be used both by corporates and banks to offer more advanced financing options. The information is not limited to the corporate and its own bank, but can be used by various parties in the supply chain to make effective use of their excess cash or replenish their short term cash needs by using a future payment by a well respected company as collateral for financing.

TWIST has analysed the basic business process flows for a payer initiated, payee initiated or bank initiated working capital financing option.

WCF PROCESS OVERVIEW

Payments with a due date in the future can be used by various parties in the chain to manage or finance their working capital. Parties can agree to settle the amount before the due date to provide financing to the payee. As the amount is paid early, a discount will be applied to the amount due to reflect the interest (with a mark up for risk) for the period of early payment.

Parties can have different objectives in suggesting early payment. The following scenarios can be identified:

Payer Initiated

A company that is obliged to pay a certain amount in the future and has a surplus of cash available can offer to its payee to pay early and apply a discount to the gross amount for the time difference. The discount will lower the cost of the transaction and should outweigh the potential interest earned on the surplus cash.

If parties agree to the early payment, the discount details need to be included in the payment message as information to the payee. This information is similar to remittance details, but does not need to be directly linked to an individual payment. These data are not sent to the accounts receivable department (they are only interested in the gross amounts), but to the financing or treasury department that negotiated the financing arrangement.

The benefit for the payee can be twofold: The first is early receipt of funds which might cover financing needs. The second is a potential price advantage depending on the status of the counterparty involved (the risk mark up in the discount can be lower as the level of certainty of the payment is higher).

The following diagram shows the process flow in this situation.

Payee Initiated

A company that has outstanding accounts receivable has an incentive to reduce the amount of accounts receivable and thus limit the size of its working capital. As soon as the payee knows that a future payment can be expected (e.g. it has received information that the payment is approved by the payer), the payee can approach banks with a request to provide an advance payment (short term loan) which again will be the discounted amount of the future payment. Although it would be natural to approach the banks involved in the processing, any bank could be approached to provide this short term financing.

Various alternatives are open for the payee to make financing arrangements:

The payee can negotiate a portfolio of accounts receivable (all or a selection) to be included in a factoring trade. In this case, the factor company will pay a discounted amount to the payee based on the total amount of accounts receivable minus a discount that reflects interest, risk and a profit margin for the factor company. The future payment will then be made to the factor company and not to the payee. This is typically an up front arrangement.

A payee can also use selected transactions for higher amounts to individually negotiate early payment. It could then select the most favourable transactions, e.g. payments to be made by companies that have a better credit rating than the payee to benefit from price differences.

The level of certainty of future payment depends on the creditworthiness of the payer. A positive assurance from the payer (by making the payment unconditional and irrevocable, also referred to as ‘buyer assured’ payment) contributes to the negotiability of the payment. A further enhancement could be a positive assurance from a bank based on the future payment by the payer. The bank will then guarantee the payment and take over the risk of non-payment by the payer (also referred to as ‘bank assured’ payment). This model may be more suitable in cross border transactions in which the payee’s bank has insufficient information on the creditworthiness of the payer and the payer’s bank takes its place.

The following diagram shows the process flow in a payee initiated situation.

Bank Initiated

A bank may have knowledge of future payments, certainly in cases where these payments do not reside with the corporate but in a payment warehouse of a banking service provider. A bank may select transactions that might be suitable for offering advances/short term loans to the payee.

The process is similar to the payee initiated example. The bank will offer a discounted amount to the payment due in which it takes over the settlement risk. The bank’s compensation will consist of interest, risk mark up and profit margin. Depending on the status of the parties involved, the offer might be beneficial for the payee in lower financing cost.