Verification of payee services from the Philippines for EU payment providers

Executive Summary

• The Manila company has a supported route as a technical supplier if its actual service remains within that role. A first contract should cover integration, processing and evidence handling under an established provider's control. Authoritative matching also needs the responding payment provider's mandate and account records. Receiving a name and IBAN from the Irish requester cannot establish who holds the beneficiary account. (European Union (Payment Services) Regulations 2018, SI 6/2018, reg 4(1)(j), as amended; Regulation (EU) No 260/2012, art 5c(1)(a).)
• The Irish payment institution's verification duty already applies to in-scope ordinary and instant euro credit transfers. Its deadline was 9 October 2025. The separate 9 April 2027 concession for payment institutions concerns providing instant transfers, and does not postpone verification. Verification must be free to payment service users. (Regulation 260/2012, arts 1, 5a(8), 5b(2), 5c(9).)
• A routing and/or verification mechanism, or RVM, performs scheme functions for payment service providers. The published European Payments Council (EPC) instruments contain no express EU or SEPA establishment bar for an RVM applicant. Direct application by the Philippine entity is a conditional option, requiring qualification, directory arrangements and customer mandates. Subcontracting through another RVM does not itself exempt an autonomous routing or verification service. (EPC218-23, VOP Scheme Rulebook v1.1, §§2.1, 4.4; EPC098-25, RVM Agreement v1.0, cl 4 and Annex I.)
• A false match can produce a statutory refund where the specified verification failure causes defective execution. The payer's payment provider must then refund without delay; the responsible payee provider or payment initiation provider may owe it compensation. Recovery from the software company requires a separate contractual or applicable national-law basis. A valid match does not establish the payee's honesty. (Regulation 260/2012, art 5c(8).)
• Verification of payee outsourcing leaves the Irish institution responsible for its service. It must give the Central Bank at least 30 days' notice before outsourcing an operational function relating to payment services. It must also assess the arrangement under the EU Digital Operational Resilience Act (DORA). The contract must support supervision, incident response and exit, with additional terms where the service supports a critical or important function. (SI 6/2018, regs 30(7)–(10), 31; Regulation (EU) 2022/2554, arts 28–30.)
• Philippine access to identifiable EU payment data needs a lawful processing arrangement and a lawful international transfer. EU hosting does not remove the transfer when a separate Manila processor can access the records. Appropriate contractual clauses, an assessment of local law and effective safeguards must cover the actual processing chain. (Regulation (EU) 2016/679, arts 28, 44–46; Implementing Decision (EU) 2021/914, annex, cls 14–16.)
• The Philippine foreign-resident-data exception is limited. Security obligations survive, and the company cannot infer an exemption from an EU IBAN or foreign customer alone. An own-system processing service also engages the National Privacy Commission's specific registration rule. Payment-system regulation depends on the functions performed, including any later payment processing. (Republic Act No 10173, s 4(g); implementing rules, ss 5(f), 6; NPC Circular 2022-04, s 5(B); Republic Act No 11127, ss 4, 10.)
• The first live service should follow approved role, matching, data-transfer and incident schedules, tested against the current EPC specifications. Expansion to direct RVM operations or payment initiation requires a fresh decision on functions and permissions. Qualification, customer approval and a liability cap each address different obligations; none substitutes for the others. (EPC098-25, cls 4, 12.4, 13.2 and Annex I; SI 6/2018, regs 4(1)(j), 90; Regulation 2022/2554, art 30.)

The responding provider supplies the authority for the match

The first sale should separate requesting-side integration from verification against the beneficiary's account records. The Irish institution is the requesting payment service provider, or PSP, when it serves the payer. The responding PSP services the beneficiary account. Article 5c requires that responding PSP, on request, to verify the correspondence between the proposed name and account identifier. The Irish PSP must arrange the check and communicate the required result before offering payment authorisation. (Regulation 260/2012, art 5c(1)(a).)

The proposed name and International Bank Account Number, or IBAN, travel from the payer to the Irish PSP, through an authorised routing arrangement, to the responding PSP or its authorised verification service. The response returns to the Irish PSP for presentation to the payer. An RVM can route these messages, conduct verification by agreement with the responding PSP, or perform both functions. A software subcontractor supplies a defined component within that arrangement. The same company can perform more than one role, but each role needs its own authority and responsibilities. (EPC VOP Scheme Rulebook v1.1, §§1.3, 2.1, 2.3 and 3.4, PT-01.05.)

This distinction changes the Manila product proposal. A request received from the Irish institution contains the payer's assertion about the beneficiary. It does not establish the beneficiary's registered name or confer access to another PSP's account database. The first customer can buy integration and processing that obtain the authorised respondent's result. If the Manila engine performs the authoritative comparison, the responding PSP must authorise that function and the necessary access to its controlled records. A second EU PSP asking for response handling provides a possible respondent relationship only if it actually services the relevant accounts and delegates the work.

The EPC Directory Service, or EDS, supplies participant, identifier and routing information. It does not supply the underlying account-holder names. A separate lookup identifies the PSP's business identifier code (BIC) from an IBAN. Directory connectivity therefore solves a routing problem, not the missing authority to compare account records. A contract granting access to directory data cannot support a separate customer-name database. (EPC330-25, EDS Terms and Conditions v1.0, cls 3–4; EPC, EDS Local File specification.)

Technology-neutral legislation permits outsourced implementation. It still assigns the verification to identified PSPs. A supplier cannot improve an authorised no-match or unavailable response into a match using its own unapproved alias list. The first service description should identify which party owns the authoritative records, which party makes the comparison and which party merely transports the result.

The Irish institution's verification duty is already operative

The Irish payment institution must apply verification to the euro credit transfers within Regulation 260/2012's scope. Article 1 generally requires both PSPs, or the sole PSP, to be located in the Union. It also excludes specified transactions, including money remittance and certain payment-system transfers. Membership of the Single Euro Payments Area (SEPA) alone does not establish statutory coverage. The institution's actual account-to-account service matters more than the broad description “payments”. (Regulation 260/2012, arts 1–2.)

Article 5c covers ordinary and instant credit transfers. Euro-area PSPs had to comply by 9 October 2025. Article 5a(8) gives euro-area payment institutions and electronic money institutions until 9 April 2027 to provide the relevant instant-transfer sending and receiving services. That later date does not amend Article 5c(9). An Irish institution cannot use it to defer verification for credit transfers it already provides. The requirement is free provision to all payment service users, not a separately chargeable protection option. (Regulation 260/2012, arts 5a(8), 5b(2), 5c(9).)

The second PSP's Member State must be identified before determining its statutory compliance deadline. Article 5c gives PSPs in non-euro Member States until 9 July 2027; Article 16(9) addresses subsequent euro adoption. A voluntary early service can still create contractual and data-protection obligations. The broader payment timetable is explained in Licentium's EU instant euro payments guide.

The check must follow immediately after receipt of the relevant beneficiary details and precede the opportunity to authorise the transfer, regardless of initiation channel. Paper orders have a specific rule at receipt, with an exception where the payer is absent. For a legal-person payee, qualifying identifiers can be used when the channel and respondent's records support them. Accounts held for multiple payees require the additional identification process in Article 5c(1)(c). These alternatives do not permit a generic name-only engine to claim coverage of every payment channel. (Regulation 260/2012, art 5c(1)–(4).)

Nonconsumer users must be able to opt out when submitting multiple payment orders as a package and opt back in at any time. That exception does not extend to consumer transfers or a general opt-out for individual business payments. The Irish PSP should record the eligible user's election, the package concerned and the required warning. The software must preserve those distinctions in its workflow. (Regulation 260/2012, art 5c(6)–(7).)

The limited software service can remain outside payment-service authorisation

The stated service supports a technical-supplier position under Irish payment law. The Manila company does not hold funds, operate customer accounts or decide whether the payer may authorise a payment. Irish regulation 4(1)(j) excludes specified technical support supplied without possession of the transferred funds, including data processing and ICT services. It expressly excludes payment initiation and account information services from that exclusion. (SI 6/2018, regs 2, 4(1)(j), as amended by SI 12/2025, reg 8(b); Directive (EU) 2015/2366, art 3(j).)

The absence of fund possession is therefore necessary to this technical exclusion, but insufficient to determine the service. A payment initiation service initiates an order at a user's request for an account held with another PSP. A provider can perform that function without ever possessing the money. An account information service has its own statutory definition; a processor's limited account-name comparison does not automatically become that service merely because it handles account data. Classification follows what the company offers, its permissions and the customer relationship. (SI 6/2018, reg 2 and Schedule, paras 7–8.)

The proposed expansion into altering payment instructions or initiating transfers crosses the present product boundary. Taking the payer's instruction and initiating the transfer needs a separate authorisation analysis. Even an authorised payment initiation provider must not modify the amount, payee or other transaction features. Silently replacing the beneficiary or IBAN is not a product change cured merely by obtaining that status. The payer must control any revised instruction through the legally appropriate process. (SI 6/2018, reg 90(4)(a), (h).)

The first contract should reserve payment-order acceptance, account operation, beneficiary changes and execution to the appropriate PSP. API permissions should implement that reservation. A contractual description as “software” carries little weight if the supplier actually performs an independently regulated function.

Direct RVM entry is a conditional option for the Philippine entity

The Philippine company can investigate direct qualification under the published EPC terms. They contain no express EU or SEPA incorporation requirement for an RVM. The rulebook's geographical and authorisation conditions for PSP participants concern a different category. The RVM Agreement's qualification process addresses legal entities without importing those PSP eligibility conditions. Those separate categories leave a conditional application route for the Philippine entity, without an entitlement to acceptance. (EPC VOP Scheme Rulebook v1.1, §§2.1, 4.4; EPC RVM Agreement v1.0, Annex I.)

The operative scheme documents are the 2026 rulebook v1.1, inter-PSP API specifications v1.1.1 and API Security Framework v2.1, effective on 20 September 2026. They are private scheme instruments. Legislation requires verification, while EPC contracts specify how participants and their appointed providers use this scheme. Qualification does not confer payment-service authorisation or establish compliance with privacy law. (EPC218-23 v1.1, §§0.5, 4.2; EPC103-24 v1.1.1, cover and §0.2; EPC164-22 v2.1; EPC098-25, cl 13.2.)

A direct applicant needs the EPC agreement, applicable fees, initial API Reference Toolbox self-certification, a suitable BIC and Swift/EDS onboarding. It also needs PSP service agreements, the relevant directory delegations, authorised security credentials and civil and professional liability insurance covering the EPC-facing risks specified in clause 9.5. Its VOP services must be supplied to or for registered scheme participants. A test result, directory login or BIC alone does not complete that chain. (EPC098-25, cls 4.2–4.6, 5.1, 9.5 and Annex I; EPC127-25, EDS Onboarding and Registration Guide v1.3, §§3–6.)

The initial subcontract route can reduce the work needed before the first sale, provided the qualified RVM controls the service into which the software is incorporated. It is not a blanket exception. The rulebook recognises indirect RVM connections and permits routing and verification to be performed by different actors. If the Manila company independently offers those functions, placing another RVM in front of it does not settle its own qualification status. The parties should classify the actual architecture before committing to production. (EPC VOP Scheme Rulebook v1.1, §2.1.)

Qualification also cannot simply be borrowed. Assignment or sublicensing of rights under the RVM Agreement, including to affiliates, needs EPC's prior written consent. This restriction does not prohibit every ordinary technology subcontract, but it defeats a proposal to use another company's personal qualification as the supplier's own. Direct qualification becomes commercially preferable when the company wants its own scheme service, customer mandates and operational control. An EU subsidiary may assist procurement or data arrangements, but the published RVM terms do not make one a universal entry condition. (EPC098-25, cl 12.4.)

Directory and certificate access require specific permissions

The technical supplier can receive controlled directory access without acquiring an independent right to exploit EDS data. The current terms expressly permit participant and proxy-holder subcontractors to use that information for technical consumption within the scheme purpose. They preserve the principal's accountability and impose confidentiality and use restrictions. General redistribution, a separate directory product and unrestricted sublicensing do not follow from this permission. (EPC330-25, cls 3–5, 16.)

The role schedule should identify the participant or proxy holder granting access, the permitted data, the technical method and who maintains current routing information. The second PSP's request for directory connectivity needs this schedule even if the Manila company already serves the Irish requester. A second customer relationship does not expand the first customer's delegation.

Certificate arrangements need the same precision. The security specifications distinguish authentication for a represented PSP from the credentials used at a responding endpoint. The parties must document certificate identity, authorised custody, use, renewal and revocation. Informal sharing of a customer's credentials is not a substitute for a permitted implementation. Directory access and certificate permissions should be removed or transferred through an agreed exit process. (EPC API Security Framework v2.1, §§4, 6, 8 and Annex 3; EPC127-25 v1.3, §§3–6.)

Matching policy must distinguish legitimate variation from a false assurance

The responding PSP should approve the matching policy and authoritative name sources before the supplier applies them. EU law recognises a legal person's commercial or legal name. An alias is therefore not inherently improper. The question is whether the alternative name belongs to the account holder and whether the comparison justifies the result returned. (Regulation 260/2012, arts 2(1d), 5c(1)(a)–(b).)

The EPC's matching recommendations address case, diacritics, spacing, spelling and verified commercial names. They are nonbinding recommendations; the responding PSP retains responsibility for its chosen criteria. No universal similarity score or edit-distance threshold creates a legal safe harbour. The supplier should test transliteration, reordered names, ambiguous short names, stale commercial-name records and deliberate impersonation against the actual customer population. Those tests are implementation recommendations, not prescribed numerical standards. (EPC288-23, Recommendations for the Matching Processes v1.0, introduction and §§II–III.)

Joint accounts need distinct treatment. Matching against one holder must not result in disclosure of another holder's name through the close-match response. Legal-person identifier matching has different exact-match logic from fuzzy name comparison. A single generic “similarity” setting cannot resolve those requirements. The approved policy should specify the result for each category and the fields that may be returned. (EPC VOP Scheme Rulebook v1.1, §1.4; EPC288-23, §§II.1–II.2, III.)

Normalisation must also occur in the correct place. A routing intermediary cannot assume permission to rewrite a scheme request in transit. Preparation before the requesting PSP creates the request, and comparison within the authorised respondent's matching process, require defined rules that preserve the original input. The supplier should not silently rewrite a routed name to improve its match rate. (EPC VOP Scheme Rulebook v1.1, §2.3; EPC098-25, cl 4.2; EPC156-26 v0.2, approved RVM meeting minutes, §5, p 4.)

The contract should assign policy approval to the responding PSP and implementation responsibility to the supplier. It should require controlled releases, regression tests and rollback for harmful changes. Approval of a policy does not excuse a supplier that implements it incorrectly. Conversely, an engine cannot compensate for an unauthorised alias or stale source record merely by producing a technically consistent score.

Warnings and outages require different customer treatment

The Irish PSP must preserve the meaning of each result. A close match calls for the associated name to be indicated to the payer. A mismatch requires the prescribed warning about sending money to an account not held by the intended payee. Verification must not prevent the payer from authorising the transfer merely because of that result, and the PSP must explain the effect on liability and refund rights. (Regulation 260/2012, art 5c(1)(a), (5), (7).)

Unavailable is not equivalent to a successful check. The EPC API's NOAP result and technical errors must remain distinguishable from a match. Under rulebook v1.1, the normal maximum execution cycle for receiving a VOP response is five seconds, subject to its specified timing rules. The service contract should set measurable processing and dependency budgets within that cycle, together with timeout, retry and escalation behaviour. A service-level credit does not establish that the statutory verification duty was met. (EPC103-24 v1.1.1, §§2.3, 4.2.5, 4.4; EPC VOP Scheme Rulebook v1.1, §3.3.2.)

Article 5c(5) does not create a general right to bypass a failed service and treat the transfer as compliant. The Commission staff's non-binding implementation clarification expressly rejects that interpretation. For a payee PSP that cannot be reached for technical reasons, the same clarification says that the payer should be told verification was not possible and must still be able to authorise, with liability determined under Article 5c(8) according to where the technical problem occurred. The Irish PSP must approve a lawful outage procedure and accurate customer messaging. It should not promise that every unavailable result permits execution or that payer consent releases it from verification duties. (Regulation 260/2012, art 5c(1), (5), (8); Commission staff, Instant Payments Regulation implementation clarifications, updated 28 July 2025, questions 141–143 and 146, pp 61–63.)

A warning override should be recorded as the payer's choice following the actual message shown. It cannot repair a missing check or a misleading full-match assurance. Logs must distinguish a genuine mismatch followed by informed authorisation from an outage or incorrectly presented result.

A false alias match engages a causal refund test

In the failure examined here, the API incorrectly treats an alias as a match and the payer transfers money to a fraudster. The payer-facing question is whether a verification failure within Article 5c(8) caused a defectively executed transaction. A wrong result is relevant evidence, but the existence of a fraud loss alone does not establish every element. (Regulation 260/2012, art 5c(8).)

The investigation must establish which name was entered, whose account the IBAN identified, whether the alias legitimately corresponded to that holder and which party supplied the incorrect response. It must then assess whether the noncompliance caused the transfer to the unintended payee. A fraudulent invoice using an invented alias differs from a transfer to the correctly identified account of a dishonest seller. Verification compares the supplied beneficiary details with account records; it does not promise performance of the underlying commercial bargain.

Where the payer PSP's paragraph 1 failure, or a payment initiation provider's paragraph 2 failure, results in defective execution, the payer PSP must refund the transferred amount without delay and restore the account where applicable. It cannot defer that remedy until its supplier accepts fault or an insurer pays. If the payee PSP or payment initiation provider failed its own Article 5c obligations and thereby caused the relevant noncompliance, that actor must compensate the payer PSP for the resulting financial damage. Further payer loss may fall under the law governing the relevant PSP contract. (Regulation 260/2012, art 5c(8).)

The rule limiting liability for an incorrect unique identifier is expressly conditional on compliance with Article 5c. An IBAN-only disclaimer cannot displace that condition. A payer who proceeds after a compliant warning may face a different outcome from one who relied on a false match. The warning, its timing and the actual authorisation therefore form part of the evidence, not a universal waiver. (Regulation 260/2012, art 5c(7)–(8); SI 6/2018, reg 111.)

If the payer never consented to the payment, the separate unauthorised-payment rules must be considered. Irish regulation 97 generally requires immediate reimbursement, no later than the end of the business day following the PSP's noting or receiving notice of the transaction. Its exception requires reasonable grounds to suspect fraud, communicated in writing to the relevant national authority. Authentication records alone do not necessarily prove authorisation. An authorised payment induced by deception should not be labelled unauthorised merely to select that remedy. (SI 6/2018, regs 88, 95–98.)

Supplier recovery needs a contract that can be enforced

IBAN name matching liability should be allocated by cause and control across the contract chain. Article 5c's express compensation provision identifies the payee PSP and payment initiation provider; it does not create an automatic statutory indemnity from every software supplier. The EPC's interparticipant liability provisions operate between scheme participants. Neither set of rules fixes the Manila supplier's contractual cap. (Regulation 260/2012, art 5c(8); EPC VOP Scheme Rulebook v1.1, §4.9.)

The supplier contract should cover defective matching code, unauthorised policy changes, inaccurate supplied records, stale data, routing failures and failure to preserve evidence. It should distinguish the party approving an alias from the party corrupting or misapplying that approval. The Irish institution needs enforceable recourse through its actual contracting party; an RVM's indemnity is weakened if its subcontract contains narrower obligations or insufficient recovery rights.

A negotiated cap should be tested against plausible aggregate false-match losses, investigation costs, privacy exposure and interruption of service. The rulebook cap applies to scheme claims, does not apply to wilful intent and preserves claims under applicable law or other contracts. Transaction-value limits between participants do not automatically flow into supplier contracts. Relevant indemnities, exclusions, deductibles and insurance cover need to be compared expressly. Unlimited liability without recoverable assets can be less useful than a supported obligation with credible cover and effective evidence access. (EPC VOP Scheme Rulebook v1.1, §4.9.2.)

The agreement should specify governing law and dispute resolution. An Irish court generally recognises a contractual choice of law under Rome I, subject to applicable mandatory rules. That choice does not make an Irish judgment automatically executable against Philippine assets. Philippine recognition rules permit specified challenges and require a local enforcement route. (Regulation (EC) No 593/2008, arts 2–3, 9, 21; Philippine Rules of Court, Rule 39, s 48; BPI Securities Corp v Guevara, GR No 167052, 11 March 2015, 755 Phil 434.)

Commercial arbitration merits comparison where the cost and likely claims justify it. Ireland and the Philippines are New York Convention parties, and Philippine legislation provides a recognition route for qualifying foreign awards, subject to Convention defences. Arbitration still requires a valid agreement, suitable procedure and assets against which to recover. The contract should also preserve prompt incident cooperation and appropriate interim relief. The EPC agreement's Belgian-law and Brussels-court terms concern that separate contract; they do not automatically govern the customer-supplier agreement. (Convention on the Recognition and Enforcement of Foreign Arbitral Awards 1958, arts I, III–V; Republic Act No 9285, ss 42–45; EPC098-25, cl 11.)

The data contract must follow the actual processing roles

For their respective payment services, the PSPs normally act as controllers under the General Data Protection Regulation (GDPR), since they determine why verification is performed. A supplier processing their data only on documented instructions can be a processor or subprocessor. The allocation depends on actual purposes and decisions, not the contract's labels. A supplier that creates its own cross-customer alias database or reuses identifiable payloads to train a commercial product needs a separate controller and lawful-basis assessment for that activity. A separate GDPR assessment would not override the scheme's restrictions on using request and response data. (Regulation 2016/679, arts 4(7)–(8), 28(10); EPC VOP Scheme Rulebook v1.1, §§4.7(19), 4.8(17).)

Names and IBANs relating to identifiable individuals are personal data. Corporate-name processing can also include sole traders, representatives or joint holders. For processing necessary to discharge its statutory verification obligation, a PSP can rely on the GDPR legal-obligation basis. That basis does not authorise every additional dataset or the supplier's independent reuse. The processing must remain limited to its lawful purposes and necessary fields. (Regulation 2016/679, arts 4(1), 5–6.)

The Article 28 agreement should identify the controller, processor chain, instructions, data categories, processing locations and permitted recipients. It must cover confidentiality, security, assistance, audit evidence, deletion or return and subprocessor authorisation. General written authorisation requires advance information about intended subprocessor changes and an opportunity to object. These terms should correspond with the participant's scheme-purpose restrictions. (Regulation 2016/679, art 28(2)–(4); EPC VOP Scheme Rulebook v1.1, §§4.7(19), 4.8(17).)

The EPC agreements' clauses about staff information do not classify the payer/payee payload. A separate processing schedule is needed. Nor does the scheme's logging requirement justify indefinite retention of complete request and response bodies. The security specification requires enabled, integrity-protected audit logging, but its suggested six-month retention period is a recommendation. The actual retention schedule must reflect necessity, applicable duties and defined dispute holds. (EPC098-25, cl 14; EPC330-25, cl 15; EPC API Security Framework v2.1, §12; Regulation 2016/679, art 5(1)(e).)

A useful evidence design separates technical metrics from restricted payment records. It preserves the request identifier, timestamps, response, authorised source, matching-policy version, relevant transformations and customer-warning handoff for an approved period. The parties should screen the actual processing for a data protection impact assessment and complete one where the GDPR's high-risk test is met. A numerical match score alone is not a complete audit trail. (Regulation 2016/679, arts 25, 32, 35.)

Philippine processing requires a lawful transfer as well as security

The proposed Philippine processing requires an international-transfer arrangement whenever the EU exporter makes personal data available to a separate Manila recipient. Remote access is sufficient; the server's EU location does not remove the transfer. The European Data Protection Board (EDPB) expressly addresses that distinction in its final transfer guidance. The Philippines has no Commission adequacy decision, so the parties need another applicable Chapter V route. (Regulation 2016/679, arts 44–46; EDPB Guidelines 05/2021, v2.0, paras 7–9 and example 11.)

The 2021 standard contractual clauses can provide controller-to-processor protection under Module Two or processor-to-subprocessor protection under Module Three, where the Decision's scope conditions are met. Its clauses concern importers whose relevant processing is not already subject to the GDPR. The parties must assess that point rather than assume every Philippine company falls outside Article 3. The transfer instrument must cover the actual exporter-importer relationship; an Article 28 agreement alone is insufficient. (Implementing Decision 2021/914, art 1 and annex; Regulation 2016/679, arts 3, 28, 46.)

Clause 14 requires a documented assessment of the destination's laws and practices and the circumstances of the transfer. Clauses 15 and 16 address public-authority requests and inability to comply. Philippine law contains preservation, warranted-disclosure and technical-assistance powers that must be assessed against the importer's actual role, records and access. The assessment must consider restrictions on notification, accessible plaintext and who controls encryption keys. (Decision 2021/914, annex, cls 14–16; Republic Act No 10175, ss 13–15.)

Encryption in transit and at rest does not resolve a transfer risk where the importer needs intelligible data and local authorities can compel access that defeats the required protections. The EDPB's supplementary-measures recommendations explain that limitation for relevant plaintext-processing scenarios. Contractual promises cannot bind foreign public authorities. (EDPB Recommendations 01/2020, v2.0, para 57 and Annex 2, use cases 6–7 and para 99.)

The first release should permit Philippine production access only after the parties establish an effective transfer arrangement for that access. If they cannot, the service must change. EU execution with no Philippine access to identifiable production records, restricted support using synthetic data, or a different processing arrangement can be assessed against the actual architecture. An EU subsidiary with unchanged Manila access would leave the transfer issue in place.

Philippine privacy duties survive the export-service label

The Manila company must address the Data Privacy Act's foreign-data exception precisely. Section 4(g) concerns information originally collected from residents of foreign jurisdictions in accordance with their laws and processed in the Philippines. The implementing rules preserve security requirements and limit the exception to the minimum necessary extent. They also place the burden of proving the foreign law on the party invoking the exception. An EU account identifier or an overseas contract does not establish those conditions. (Republic Act No 10173, s 4(g); implementing rules, ss 5(f), 6.)

The National Privacy Commission (NPC) applied that limited interpretation in an opinion concerning a Philippine processor handling bank-client data collected from US residents. Security obligations remain. The implementing rules also preserve applicable principles and rights unless directly incompatible with the exception. The opinion is a fact-bound regulatory interpretation, not an exemption issued to this company. The supplier should classify datasets by their original collection and residence facts; local staff records and Philippine-origin enrichment may require different treatment. (Data Privacy Act implementing rules, s 6; NPC Advisory Opinion 2024-019, 26 December 2024, pp 2–5.)

A Manila provider following documented customer instructions fits the personal information processor role on those facts. The local outsourcing contract must cover processing particulars, instructions, locations, confidentiality, security, further processors, assistance, deletion or return and audit information. A controller-to-controller data-sharing agreement does not replace the required processor terms. (Republic Act No 10173, ss 3(i), 14, 20–21; implementing rules, ss 43–45.)

Registration requires attention even for a small company. NPC Circular 2022-04 contains employee, sensitive-data and risk triggers, but also expressly requires registration where a processor uses its own system as a service to process personal data. If the company uses its own system to supply the API, that rule applies. The company should settle the system and data protection officer registration requirements before production, including the applicable filing timetable. A registration certificate proves registration, not the legality or accuracy of the service. (NPC Circular 2022-04, ss 5–8, 13.)

The current security circular requires controls addressing privacy assessment, access, retention, remote work, logging, secure disposal and continuity. The contract should translate those duties into the actual support and processing design, including tenant separation and controlled staff access. The foreign-data exception cannot justify omitting that work. (NPC Circular 2023-06, ss 4–5, 9, 12–14, 21–22, 28–30.)

A wrong match and a reportable data breach are different events

The parties should investigate every material false match without automatically classifying it as a notifiable personal-data breach. Incorrect matching can arise from a permitted but defective algorithm, corrupted records, unauthorised access or an unlawful disclosure. Those facts determine which security and notification rules apply. For a GDPR personal-data breach, the processor must notify the controller without undue delay. The controller must notify the supervisory authority without undue delay and within 72 hours of awareness where feasible, unless the breach is unlikely to risk individuals' rights and freedoms. A high risk also requires communication to affected people without undue delay, subject to Article 34's exceptions. (Regulation 2016/679, arts 4(12), 33–34.)

The Philippine controller must notify the NPC and affected people when the breach involves sensitive personal information or information usable for identity fraud, there is reason to believe that information may have been acquired by an unauthorised person, and the controller or NPC believes that the acquisition is likely to create a real risk of serious harm. Its 72-hour period can begin with the controller's or processor's knowledge or reasonable belief, so a slow internal escalation cannot create a fresh clock. A request to postpone notification does not itself suspend the duty. (NPC Circular 16-03, ss 11, 15–18; NPC Advisory 2026-02, s 2(C)–(D).)

The incident schedule should require prompt supplier escalation, preservation of relevant records and named decision-makers for each jurisdiction. It should distinguish privacy notification, payment remediation, scheme notification and DORA reporting. A technical incident may require several responses, while an isolated error may meet only some of those tests. Contractual investigation periods must not delay a statutory payer refund or mandatory notification.

Philippine payment-system status follows the functions performed

The narrow comparison service supports a technology-supplier position under Philippine payment-system law, but absence of money custody is not decisive. The National Payment Systems Act and Bangko Sentral ng Pilipinas (BSP) rules address payment-system operation, control or maintenance and the provision of payment platforms or processing. A company can perform relevant functions without holding customer funds. (Republic Act No 11127, ss 4(b), 4(l)–(r), 5, 10; BSP Manual of Regulations for Payment Systems, §502.2.)

The BSP's published explanation distinguishes incidental technology provision from performing operator activities in the provider's own name. Applied to the stated API, a prepayment comparison returned to a PSP can remain a supplied technical component. Handling verification requests, responses and directory traffic does not automatically amount to processing payment orders. The actual message types, operating responsibility and customer permissions determine the boundary. (BSP, Frequently Asked Questions on OPS Registration, p 4.)

The initiation variant requires a fresh assessment on both sides of the corridor. Operating payment transmission, processing or the arrangements enabling funds transfers may require registration as an operator of a payment system. A foreign customer does not by itself remove functions carried out in Manila from Philippine analysis. If registration is required, the current application instructions are BSP Memorandum M-2026-039, which supersedes the 2019 instructions and requires functional self-assessment and supporting operational records.

The Irish customer is not a Philippine-supervised bank merely because its supplier is in Manila. Philippine bank-outsourcing rules should therefore not be imposed indiscriminately on this arrangement. The supplier's own activity and any later Philippine regulated customer create separate questions. The initial role schedule should prohibit unapproved expansion from verification-message handling into payment execution or processing.

DORA determines what the Irish customer must obtain from its supplier

The Irish payment institution must assess the recurring API service as an information and communication technology (ICT) third-party arrangement under DORA. The Act applies to payment institutions from 17 January 2025, and the institution remains responsible when it uses external ICT services. It must assess whether disruption to this mandatory preauthorisation check would materially impair its services or continued compliance. That assessment determines whether the API supports a critical or important function. These procurement duties bind the institution; its contract places delivery obligations on the Manila supplier. (Regulation 2022/2554, arts 2(1)(b), 3(21)–(22), 28(1), 64.)

That functional assessment differs from designation of the supplier itself as a critical ICT third-party provider. DORA's requirement for a designated third-country provider to establish an EU subsidiary within 12 months does not apply automatically to every Philippine vendor supporting an important service. The present choice between a Philippine company and an EU subsidiary should not be decided by conflating those categories. (Regulation 2022/2554, art 31(12).)

For the ICT contract, the institution needs a clear description of services and subcontracting, processing and storage countries, advance notice of location changes, security duties, data recovery and return, service levels, incident assistance at no additional cost or at a cost determined in advance, regulator cooperation and termination rights, together with conditions for the supplier's participation in ICT security awareness programmes and digital operational resilience training. A critical or important function requires further provisions for measurable service levels, material-event reporting, continuity and testing, access and audit, and an adequate transition on exit. The parties must define these rights so the institution and its authorities can exercise them through the actual delivery chain. (Regulation 2022/2554, arts 28–30.)

For critical or important ICT subcontracting, Delegated Regulation 2025/532 requires assessment of the chain and its risks. The principal provider remains responsible for subcontracted performance. The contract must address permitted subcontracting, monitoring, locations, security, continuity and access rights. Material changes require advance notice and a reasonable period for approval or objection, with termination rights in the specified circumstances. Its no-objection mechanism should not be confused with the separate GDPR rules governing subprocessor authorisation. (Delegated Regulation (EU) 2025/532, arts 3–6.)

The Philippine location makes enforceability, data access, insolvency and recovery practical diligence issues. Certifications and pooled reports can support assurance, but should not leave the institution or supervisor unable to obtain the access the law requires. The exit plan should test replacement of the matching engine, recovery of records, withdrawal of credentials and continuity during migration. It should also address termination of the RVM's scheme contract. (Regulation 2022/2554, arts 28(8), 29(2), 30(3); EPC098-25, cl 8.)

Irish outsourcing law adds a minimum 30-day notification before outsourcing an operational function relating to payment services. For important functions, it imposes conditions preserving management responsibility, customer obligations and supervision; the institution remains liable for outsourced acts. It must also maintain its DORA register and provide the required information about planned critical or important arrangements. Notification is not proof of approval. A supplier should provide the diligence package early enough for the institution to meet those duties before launch. (SI 6/2018, regs 30(7)–(10), 31; Regulation 2022/2554, art 28(3).)

The first customer should launch within a defined service boundary

The recommended first route is a controlled technology subcontract with an established RVM, coupled with the correct PSP mandate for each function. For the Irish requester, that means integration, authorised routing, faithful response handling and evidence support. Respondent-side matching should begin only under the account-servicing PSP's authority, with approved records and policy. This recommendation follows the allocation of verification in law and the scheme's recognition of both direct and indirect RVM functions. (Regulation 260/2012, art 5c(1)(a); EPC VOP Scheme Rulebook v1.1, §2.1.)

Before live processing, the parties should agree the role and data-flow schedule, permitted directory and certificate use, matching policy, processing and transfer terms, service levels, audit rights, incident duties and exit arrangements. Testing should cover false positives, close-match disclosure, unavailable results, stale records, duplicate requests and recovery from failed dependencies. The evidence package should connect the original request to the authorised respondent, software and policy version, response presented, payer action and later investigation. These records support both operational correction and the causal liability test. (Regulation 260/2012, art 5c(8); Regulation 2022/2554, art 30; EPC API Security Framework v2.1, §12.)

Direct RVM operation becomes a separate release decision when the company wants to offer its own routing or verification service. It must complete qualification and onboarding, secure the relevant PSP contracts and mandates, and demonstrate current technical conformity and operational capacity. The verification of payee provider requirements therefore extend beyond a successful API demonstration. Initial qualification and any EPC-required retesting, controlled releases and continuing insurance belong in the operating plan. (EPC098-25, cls 4–5, 9.5 and Annex I.)

Several findings would require a different structure: independent initiation of payment orders; inability to obtain authoritative respondent records; restrictions on permitted subcontracting; or inability to protect the proposed Philippine transfer. Each requires a specific response, whether authorisation, a respondent relationship, direct qualification or changed data access. A sales commitment should describe the functions and permissions that can actually be delivered, with the contract allocating the remaining obligations to the parties legally responsible for them. (SI 6/2018, regs 4(1)(j), 90; Regulation 2016/679, arts 28, 44–46; EPC098-25, cl 4 and Annex I.)