Co-signing of corporate payments: current situation

We started  with an introduction post and we start the new year with clarifying a couple of concepts. Terminology around co-signing is not always used in the same way. So let’s first of all clear cut definitions and then dive into the current situation.

Mandates and signing business rules

 

Account holder – agent holding power of attorney – Customer ID

A bank account has one or more account holders, (principal). Next to that, there may be zero, one or more agents holding power of attorney.  These are contractual conditions settled at the bank.

All account holders and agents holding power of attorney do have a customer ID within the systems of the bank.  We will not go into any more details here about these account contractual concepts, just to retain that there is within the bank a list of person ID’s, that can be used to check (authenticate) a payment signature against.

Payment signing mandates and business rules in a corporate context

We focus on the processing of non-retail payments that have to be signed by more than one person.

It is the organisation in the first place who determines who can sign what, and/or what payment is to be signed by who, and by how many. Co-signing can be a practice in any kind of ‘organisation’ where two or more persons are involved: associations, SOHO’s, Professionals, SME, Corporate.

High value payments in particular often require more than one signature.

Focusing on the corporate context, we make a distinction between:

  • The signing mandates that are granted to the different persons. These are granted in function of the roles and responsibilities. Different constraints can apply: amount limits, limits on the period of time, combination of both, …. Not everybody is allowed to sign for releasing whatever amount. For instance, an accounting staff member can only sign payments up to € 2.500. For payments above € 2.500, his team leader and/or someone from Finance has to co-sign. Payments above € 25.000 always to be co-signed by CFO or CEO,…etc.
  • There are also payment signing rules, where the payment is rather the determining factor: e.g. a payment above 25.000 € is to be signed by two of the account holders.

Next to the amount, also the type of payment can be determining for who or how many have to sign: e.g. intracompany payments versus third party payments.

Master and enforcement of the mandates/signing business rules

 As said, the corporate itself determines all these rules. It is clear that the combination of such signing mandates and payment signing rules, and it’s granularity, can be complex to manage. In order to better understand the management and application of these signing rules and mandates in real-time payments processing, we make a distinction between two important aspects:

  1. Who masters the data set (signing rules and mandates)?
  2. Where in the chain and by whom are the signing rules and mandates enforced?

Mandate management covers both aspects.

We can distinguish the following scenarios:

Scenario A: The bank both masters the data set and enforces the mandates during real-time processing.

Each payment order will be checked by the bank against the set up signing rules and mandates: as long as not sufficiently/correctly signed, the payment will not be executed. It will be either queued, pending additional signature(s), or it will be rejected.

In this scenario, the bank obviously bears the full liability.

 

flow_03

 

Scenario B: The mandates are enforced by a third party platform, the bank remains master of the mandate data.

The third party platform checks if the payment order is sufficiently signed, according to the mandates as defined by the corporate and recorded at the bank. As long as the payment is not sufficiently signed, the third party platform does not release the payment order to the bank.
Such a platform typically takes care of the collection of the missing signature(s).

It is to be stressed that in this scenario the actual signing rules and mandates are still mastered within the bank’s system, though a copy is maintained in the third party platform. In this scenario the banks often check themselves if the payment is sufficiently signed, a kind of second enforcement. After all, the bank remains liable.

 

flow_04

 

 Scenario C: The corporate fully takes care of the mandate management.

The corporate ensures that the payment order is only released and sent to the bank, when sufficiently signed.

The mandates and signing rules are maintained and managed by the corporate itself, for instance within an accounting or ERP package. In this case, the corporate has an agreement with the bank that every payment order the bank receives, is sufficiently and duly signed. The bank must not check that anymore. So here, the corporate bears the liability.

This scenario is rather uncommon. We further discard it.

 

flow_05

 

Signature collection process

When a payment order arrives at the bank, it is checked whether the person who authenticated, has the right to do so. If the bank actually supports co-signing, it also checks if this signature is enough for the payment (type and amount) in question.

If not, what happens next? There is no general practice, no general process, no general rule. The way in which the banks support the collection of missing signature(s), differs from bank to bank. We elaborate the different methods below.

The co-signing feature could be supported within the bank channel itself (above scenario A) ). We refer for instance to Business online banking channels supporting the pending payments or envelope functionality  (MultiSignature SingleChannel).

More and more banks though do support a so-called MultiSignature MultiChannel (MSMC) mechanism. This mechanism offers much more flexibility to the customer, as the different persons that have to co-sign, can do so in different bank proprietary channels. This mechanism is often used in a broader context, i.e. to collect signatures for all products or processes for which more than one signature is required, like:

  • Opening an account
  • Making a transfer/payment
  • Sending a SDD collection file to the bank
  • Signing an investment profile (linked to an investment account with 2 or more account holders)
  • Mortgage loan

The insufficiently signed asset – payment in our case – is kept pending (bearing expiry periods). In function of the applicable business rules, the bank notifies the remaining person(s) to co-sign in their bank channels. The missing signatures can be ‘collected’ via

  • online banking
  • mobile banking
  • phone banking
  • agency

As soon as the payment is sufficiently signed, it is released.

 

flow_06

 

Remark: In the above mentioned scenario B, a third party platform supports the signature collection process. The required signatories all do have access/means to sign, directly in that platform, or in some corporate (ERP, …) system that is linked with the third party platform. The signatories are not able to co-sign the payment in a bank proprietary channel.

One could as such describe this concept as MultiSignature Single non-proprietary Channel. Where does PSD2 fit in all of this? We dive into this question in the next blog post.

Do you want to learn more about managing co-signing for corporate payments? Then download our in depth white paper below:

Download our white paper