Confirmation of Payee (CoP)

Confirmation of Payee (CoP) is a payee checking service that helps prevent UK domestic payments from being sent to the wrong account. It does this by making sure the payee account details provided match the details held by their provider.

As a payment service provider (PSP), Griffin is required to provide Confirmation of Payee. It works in both directions:

• Requesting a check: you can check the account details of anyone you or your customers want to pay. You can access this through our API, if you want to embed Confirmation of Payee into your platform, or through our app.
• Responding to checks: we respond to CoP requests on all Griffin accounts, so payers can verify account details before sending money to you or your customers. See Responding to CoP checks for details.

When do you need to use CoP?

How CoP applies depends on how you access Griffin:

• In our app: We enforce the use of CoP - a check runs automatically when you add a payee. If the check does not return a match, you can review the result and still choose to continue with the account details you entered.
• Over the API, for your own payments: We don't enforce CoP on payments from your own accounts, but we strongly recommend it. Our CoP API is available to all direct customers.
• Over the API, for your customers' payments: If you offer accounts to your own customers, you must make CoP available to them in their payment flows. You can use our CoP API to do this, or another CoP solution of your choice.

Performing a CoP check

When a payee's account details (name, account number and sort code) are provided, we check them against the receiving firm's records.

After the check is performed, you'll get one of the following results:

• Match: The details provided match the details at the receiving firm
• Close match: The name is similar but not an exact match, or the account type is incorrect - we'll suggest the correct details
• No match: The details provided do not match the receiving firm's records, the account does not support CoP, the account has moved to another firm, or the receiving firm could not be reached to verify the details

Instead of a result, the check can also fail with an error:

• Account not found (400): We couldn't find a valid account matching those details
• Legal person not found (400): The requester-legal-person-url does not point to a legal person we recognise
• Forbidden (403): You are not authorized to perform this action
• Simulation not allowed (422): The simulation API was called with a live organization
• Verification unavailable (503): We couldn't perform verification at this time

info

An account that has not been made available for CoP is not an error: the check returns a No match with the reason account-not-supported - because the receiving firm doesn't support CoP, the account holder has opted out, or the specific account isn't supported. If the receiving firm can't be reached at all, the check returns a No match with no reason. See Receiving a No Match.

Making a CoP request

To perform a CoP check, you need the details of the account you want to check, as held by the payee's own provider:

• name - the name on the payee's account: an individual, two named individuals on a joint account, or a business name (1-138 characters)
• account-classification - whether the payee's account is a personal or business account
• bank-id - the sort code of the payee's account
• account-number - the account number of the payee's account
• secondary-reference-data - an optional secondary reference (1-35 characters)

You also need to tell us who is making the check:

• requester-legal-person-url - a URL pointing to the legal person this request is being made on behalf of. The legal person must belong to your organization.

info

A secondary reference is extra information needed to identify certain accounts. This could be, for example, a building society roll number or a credit card number. This is an optional field and will only need to be provided if required by the account provider.

If a secondary reference is provided, it will take precedence over any other reference provided when making a payment to that payee.

Here's an example request:

curl 'https://api.griffin.com/v0/organizations/${ORGANIZATION_ID}/cop-request' \
  -X 'POST' \
  -H 'Content-Type: application/json' \
  -H "Authorization: GriffinAPIKey $GRIFFIN_API_KEY" \
  --data '
{
    "account-number": "12345678",
    "bank-id": "123456",
    "account-classification": "personal",
    "name": "John Smith",
    "secondary-reference-data": "12345678910",
    "requester-legal-person-url": "${LEGAL_PERSON_URL}"
}'

Receiving a Match

A Match result means that all the details provided - the name, account number, account type (personal or business), and, if relevant, secondary reference - match what the receiving firm has on record.

When this happens, the status of the CoP response is verified. In our app, a Match means the payee is marked as verified.

tip

When showing a Match result to your customers, make sure to provide visual confirmation that the details are verified - such as a tick ✅

Here's an example Match response:

201
{
    "cop-request-url": "/v0/cop-request/cp.ICBjb3AtcmVxdWVzdC1pZA",
    "account": {
        "account-number": "12345678",
        "bank-id": "123456",
        "account-classification": "personal",
        "name": "John Smith",
        "secondary-reference-data": "12345678910",
        "requester-legal-person-url": "/v0/legal-persons/lp.SYyKUI73W5yWJzTxqKyyBw"
    },
    "cop-response": {
        "status": "verified",
        "result": "match"
    }
}

Receiving a Close Match

A Close Match result happens when the account number (and secondary reference, if needed) matches the same details held at the receiving firm, but we find a discrepancy:

A discrepancy in payee name:

• close-match-name - the name is slightly different (like Jamie Lud instead of Jamie Lu)

A discrepancy in both payee name and account type:

• close-match-name-business-personal - the name is slightly different and a business account was provided when it's actually a personal account
• close-match-name-personal-business - the name is slightly different and a personal account was provided when it's actually a business account

Only a discrepancy in account type:

• match-name-business-personal - the name is a match but a business account was provided when it's actually a personal account
• match-name-personal-business - the name is a match but a personal account was provided when it's actually a business account

When you get a Close Match, we'll suggest the correct account details: a suggested-name when there is a name discrepancy, and a suggested-account-classification when there is an account type discrepancy.

tip

When showing a Close Match result to your customers make sure to clearly explain the reason why it's a Close Match and ask them to review the details again. Show the suggested correct details, with options to:

• Proceed with the suggested details, either by accepting them or by editing what they entered to match
• Accept and proceed with the details that did not match
• Cancel the process

Any time a customer chooses to ignore a partial or no match, we recommend displaying a warning to the customer.

Here's an example Close Match response with a name discrepancy:

201
{
    "cop-request-url": "/v0/cop-request/cp.ICBjb3AtcmVxdWVzdC1pZA",
    "account": {
        "account-number": "12345678",
        "bank-id": "123456",
        "account-classification": "personal",
        "name": "Jamie Lud",
        "secondary-reference-data": "12345678910",
        "requester-legal-person-url": "/v0/legal-persons/lp.SYyKUI73W5yWJzTxqKyyBw"
    },
    "cop-response": {
        "status": "unverified",
        "result": "close-match",
        "reason": "close-match-name",
        "suggested-name": "Jamie Lu"
    }
}

And here's an example with an account type discrepancy:

201
{
    "cop-request-url": "/v0/cop-request/cp.ICBjb3AtcmVxdWVzdC1pZA",
    "account": {
        "account-number": "12345678",
        "bank-id": "123456",
        "account-classification": "personal",
        "name": "John Smith",
        "secondary-reference-data": "12345678910",
        "requester-legal-person-url": "/v0/legal-persons/lp.SYyKUI73W5yWJzTxqKyyBw"
    },
    "cop-response": {
        "status": "unverified",
        "result": "close-match",
        "reason": "match-name-personal-business",
        "suggested-account-classification": "business"
    }
}

Receiving a No Match

A No Match result means the details you provided did not match the records by the payee’s provider. This can happen for several reasons:

no-match-name - the name provided doesn't match the name on the identified account.

no-match-secondary-ref - there's been an issue with the secondary reference - either it wasn't provided, or it doesn't match the one on the identified account.

account-not-supported - the account doesn't support Confirmation of Payee because:

• The receiving firm isn't supported
• The account holder has opted out
• This specific account isn't supported

account-switched - the account has been moved to a different firm.

You may also receive a No Match with no reason field. This means we could not verify the details with the receiving firm - for example, the firm could not be reached or does not respond to CoP checks. In this case, tell your customer that the account could not be verified, rather than that the details are wrong.

When you get a No Match, the CoP check status will be unverified.

tip

When showing a No Match result to your customers make sure to clearly explain that the details provided did not match, the reason why, and that they need to review the details again. Provide the following options:

• Accept and proceed with the details that did not match
• Edit the details
• Cancel the process

Any time a customer chooses to ignore a partial or no match, we recommend displaying a warning to the customer.

Here's an example of a No Match response

201
{
    "cop-request-url": "/v0/cop-request/cp.ICBjb3AtcmVxdWVzdC1pZA",
    "account": {
        "account-number": "12345678",
        "bank-id": "123456",
        "account-classification": "personal",
        "name": "John Smith",
        "secondary-reference-data": "12345678910",
        "requester-legal-person-url": "/v0/legal-persons/lp.SYyKUI73W5yWJzTxqKyyBw"
    },
    "cop-response": {
        "status": "unverified",
        "result": "no-match",
        "reason": "no-match-name"
    }
}

Account not found

Account Not Found happens when we can't find an account and/or receiving firm based on the details you provided.

In this case, you'll get a 400 error response with the code account-not-found.

tip

When showing an Account Not Found error to your customers make sure to clearly explain that an account was not found and that they need to review the details. Provide them with the following options:

• Edit the details
• Cancel the process

Here's an example response:

400
{
  "errors": [
    {
      "title": "Account not found",
      "detail": "Could not find an account with those details",
      "code": "account-not-found",
      "status": "400"
    }
  ]
}

Verification unavailable

Verification Unavailable means we can't check the details right now due to a service outage.

When this happens, you'll get a 503 error response. Note that this response has no code field - identify it by the HTTP status.

tip

When showing a Verification Unavailable error to your customers make sure to clearly explain that verification is not possible at this time and that they need to try again later. Provide them with the following options:

• Edit the details
• Cancel the process

Here's an example response:

503
{
  "errors": [
    {
      "title": "Service Unavailable",
      "detail": "Verification is currently not possible, please retry later",
      "status": "503"
    }
  ]
}

Responding to CoP checks

Confirmation of Payee works in both directions: when someone sets up a payment to a Griffin account, their bank runs a CoP check against us. We respond to these checks automatically for every Griffin account - there is nothing you need to build or configure.

The name we confirm

We always respond with the verified name we hold for the account holder - the name established during onboarding and verification, never a self-declared display name or trading name:

Account holder	Name we confirm
Company	The name registered at Companies House
Sole trader	The individual's own name
Individual	The individual's name

info

Sole trader accounts are classified as business accounts for CoP, but the name we confirm is the individual's name. Trading names cannot be independently verified, and confirming them would create a fraud risk - anyone could claim another business's trading name. Sole traders receiving payments should tell payers to use their personal name, and to select "business account" if asked for the account type.

We match on beneficiary names too

Where an account has a designated beneficiary who is different from the account owner, we register both names for CoP. Inbound checks then match against either the owner's name or the beneficiary's name.

This is particularly useful if you safeguard customer funds or hold client money. For example, if you are an e-money institution with a dedicated safeguarding account for one of your customers, the account is owned by you but the funds belong to your customer. Someone paying into that account can run a CoP check using your customer's name and get a match - they don't need to know the name the account is registered under.

CoP Simulator

Using the sandbox environment, it is possible to simulate a number of different CoP outcomes, for example, a full match, or no match. This can be achieved by using the CoP simulation API.

The following simulation types are available:

• full-match
• close-match-name
• close-match-name-business-personal
• close-match-name-personal-business
• match-name-business-personal
• match-name-personal-business
• no-match-name
• no-match-secondary-ref
• account-not-supported
• account-switched
• account-not-found

Simulated close matches return a suggested-name of the requested name with CloseMatch appended.

For example, to simulate the account-switched outcome, you can make the following request:

curl 'https://api.griffin.com/v0/simulation/organizations/${ORGANIZATION_ID}/cop-request/simulate/account-switched' \
  -X 'POST' \
  -H 'Content-Type: application/json' \
  -H "Authorization: GriffinAPIKey $GRIFFIN_API_KEY" \
  --data '{
    "account-number": "12345678",
    "bank-id": "123456",
    "account-classification": "personal",
    "name": "John Smith",
    "secondary-reference-data": "12345678910",
    "requester-legal-person-url": "${LEGAL_PERSON_URL}"
  }'

201
{
    "cop-request-url": "/v0/cop-request/cp.ICBjb3AtcmVxdWVzdC1pZA",
    "account": {
        "account-number": "12345678",
        "bank-id": "123456",
        "account-classification": "personal",
        "name": "John Smith",
        "secondary-reference-data": "12345678910",
        "requester-legal-person-url": "/v0/legal-persons/lp.SYyKUI73W5yWJzTxqKyyBw"
    },
    "cop-response": {
        "status": "unverified",
        "result": "no-match",
        "reason": "account-switched"
    }
}