Responding - Cloud

Delegate Your VOP Responses to Qombo

Let Qombo answer inbound VOP requests on your behalf. You provide your account-holder database, and Qombo securely stores it, validates incoming PSP requests, performs the identity match, and sends back the response — so you stay compliant with the EPC VOP scheme with minimal operational complexity.

This is one of two ways to handle the responding side of VOP. The other is Responding — On Demand, where Qombo calls your own API in real time instead of storing your data.

Endpoints

MethodPathPurpose
POST/vop/v1/exposeUpload or update account-holder records.
DELETE/vop/v1/exposeRemove account-holder records from Qombo's database.

How it works

Once your data is stored, Qombo manages the entire response process:

  1. Validates and authorizes incoming requests from other PSPs.
  2. Finds the account holder linked to the requested IBAN.
  3. Performs the identity match defined by the EPC VOP scheme.
  4. Sends the verification response back to the requesting PSP.

Your only responsibility is to keep the account-holder data up to date.

What you send

Each entry in data[] is keyed by iban and carries accountInformation:

  • Individuals — a primaryAccountHolder (and optional secondaryAccountHolder) with firstName / lastName.
  • OrganisationslegalName, optional commercialName, and companyIds[].
  • Optionally set accountType (e.g. JOINT_ACCOUNT).

Managing data updates

The IBAN is the unique identifier for each record. Submitting an IBAN overwrites any existing record for it. You can push only the records that changed or send your full database on each call — whichever fits your processes.

🚧

Overwrite semantics

POST /vop/v1/expose replaces the stored record for each IBAN in full. Include every field you want kept, not just the changed ones.