We receive Inbound CPR requests from OFIs (other financial institutions) on a daily basis and these come into our Freshdesk ‘Modulr Payments Team’ queue. 

An example of what a CPR request looks like is below - we can see here the OFIs have their own unique CPR reference as the subject and have provided all the relevant information the the agreed CPR template. They have also advised clearly whether this been customer error not bank error.

Initial Due Diligence

1. Firstly, we want to to use the Faster Payment ID (FPID) which is under ‘Payment Ref' in the email and start doing our own due diligence on the payment. Using metabase query Faster Payment ID Search we are going to search using the FPID.

We want to also ensure at this point the payment is in ‘In Scope’ as outlined by the CPR guidelines above. Follow ‘Other Scenarios’ process below if this is the case.

We can see a few things from our initial search;

 

  • Payment status is ‘PROCESSED’

  • Payment_Type confirms it is PI_FAST (Faster Payment)

  • The value date and amount match what we have been advised in the email

  • The account status is ‘ACTIVE’

  • We now have the customer ‘ABID’ and the payment ‘PBID’

Check for funds

2. Using Admin Portal we are now going to look up the account to see what the balance of the account is. As per the below snip, we can use the ‘Accounts’ function and search using the ABID.

Depending on how the account has been set up, there may not always be funds available due to their own sweeping rules. A more in depth overview of this can be found on page - Payment rules explained.

IF there are funds available, we now need to follow the process - CPR Protected Funds (same name on freshdesk)


Raise & Acknowledge CPR

Update Spreadsheet

3. We next want to fill out our CPR spreadsheet, using the information provided by the OFI and the information we now have from our metabase query.

Note - Column H ‘Today’ is a formula, so we don’t enter the date, we just need to ensure we drag the formula for this down.

Reply with acknowledgment

4. Whether we have been able to protect funds or not, if we are able to raise the CPR, we must acknowledge the CPR so the OFI know we have received their request and are working on it. We are going to do this using a canned response in Freshdesk - /c CPR Acknowledged IB

We can get the final outcome date from the spreadsheet in Step 3, as this will be worked out via a formula.

Raise with CS

5. In order to contact the customer in regards to this CPR claim, we need to reach out to our customer support team as only they can contact the customers. We can do this via Freshdesk by adding a NOTE and using 1 of 2 canned responses. 

OPTION A - Funds have been protected so we will raise this using /c Inbound Recall - funds protected

OPTION B - Funds have not been protected so we will this raise using /c CPR Inbound ACK CS. We can get the ‘RETURN DETAILS’ from the metabase query we are already using by scrolling further along.

If the CPR has been BANK ERROR,  we will not be returning to the details from metabase, as we will have been provided suspense details to return funds to, from the OFI.

6. Now we have our note in place for customer support, we want to ensure this is added to THEIR Freshdesk queue. We want to ensure we update the ‘Status’ to OPEN and the ‘Group' to MODULR CUSTOMER SUPPORT.

Once CS raise the CPR with the customer, they will link their ticket as a note in ours. This will reopen the ticket, at which point we can amend the ‘Status’ to ‘Waiting on Third Party'

Other Scenarios

Credited Intended Beneficiary

Often, upon looking up the FPID in the metabase query, we can see the ‘Intended Recipient Name’ and the ‘c_name’ (customer name) are the same, therefore, there has been no error and funds have credited the intended beneficiary. We therefore want to reject the claim, rather than raise.

1. For our own records we want to keep a note of this in our spreadsheet, in the ‘Recalls Rejected’ tab, using the reference given to us by the OFI. We are going to reject this CPR under a ‘K.’ rejection outcome category.

2. We need to now advise the OFI of this outcome by replying to the ticket. We have a canned response for this also - /c 'k.'

This will look like the below and we can now send this.

3. Lastly, we want to now close this ticket and take it out our queue. We can do this by clicking ‘Execute scenarios', choose the template ‘WIP - PayOps - Rejected Recall’ which will prefill many of the options. We lastly just need update ‘Query Type’ and ‘Issue’ and click ‘Update’.

Failed Due Diligence

When we receive a CPR claim, we need to ensure it is in scope and follows the guidelines set out above, however, if it is out of scope such as the customer just changing their mind, we can reject the claim with a 'B' outcome. For example, we can advise “Unfortunately as the customer has changed their mind and no error has occurred, as per the CPR guidelines this claim is out of scope.”. We similarly to the above, need to just update the spreadsheet with this information. 

Blocked Accounts

Occasionally, the metabase query will show the ‘a_status’ (account status) as blocked, in which case we need to find out who has blocked this account, us or the customer, so we know who to raise it with.

1. Firstly, using the customer ABID, we are going to search on Admin Portal under ‘Accounts’. We want to click on the account and view ‘Account notes’ - if we can see a note then we have blocked the account not the customer, therefore, we need to raise this with our compliance team. 

2. We can raise with the compliance team via slack #cs_compliance, leaving a message similar to the below;

3. We can then update our spreadsheet as normal and acknowledge the CPR so the remitting bank know we have received their claim. 

4. We can then leave a note on the CPR claim with a link to the slack post so it is easily traced back.

If there is no notes on the account notes, it is because it has been blocked by our client/customer, therefore, we can raise the claim as normal to CS but just let them know the account has been blocked by the customer.