GROUP PAYMENTS POLICY SUPPLIER VERSION SUMMARY FOR THIRD PARTY SUPPLIERS

Transcription

1 GROUP PAYMENTS POLICY SUPPLIER VERSION SUMMARY FOR THIRD PARTY SUPPLIERS RATIONALE The Group Payments Policy ensures that the expectations of our customers are met when it comes to their transactional needs by ensuring that Lloyds Banking (the Group) is in control of Payment transactions no matter where in the world they are initiated, processed or settled. The Payments environment is becoming increasingly regulated (e.g. Payment Services Regulations and Single Euro Payment Area (SEPA) with ever-widening scrutiny from Governments, Regulators and Central Banks. In addition, there is an increasing amount of innovation in the ways in which customers can and want to make their Payments and it is essential that these are developed in a manner that is consistent across Lloyds Banking Group and ensures ongoing compliance. Customer treatment, sanctions, financial crime, payment security, intra-day liquidity and payment systems & scheme resilience are all key risks throughout the end to end payments process of payments transactions. Lloyds Banking Group s vision is to be the best bank for our customers. The Group Payments Policy Supplier Version supports this vision by creating a framework, based on the relevant Payments Regulations, to protect our customers and to provide a consistently fair outcome for our customers. SCOPE This third party version of the Policy applies to suppliers (also referred as Third Parties), who are not a part of LBG, but are involved in the provision of goods or services to LBG Business Units in the Group; and such goods or services are considered a part of the end to end payments process performed by the Business Unit within the meaning of the Group Payments Policy. The end to end payments process in relation to suppliers is divided into key sections detailed in Mandatory Requirements, section 2 below. Suppliers are required to comply with the sections of the Policy depending on the payments related activities performed by them. In the context of this Policy a payment is defined as any movement of value in any currency, domestic or cross-border, via any channel and by any means, including (not exhaustive): Transfers between banks, customers and third parties Scheme settlements Movements over nostro and vostro accounts In scope Payment Transaction types, include (not exhaustive): Cross-border Payments Domestic schemes e.g. BACS, CHAPS, Faster Payments Paper e.g. cheques Trade Page 1 of 7

2 Intra account transfers Loan repayments All other Payment types and all Payment systems and applications are in scope. This does not include relationships with agency or correspondent banks MANDATORY REQUIREMENTS GENERAL All parties who are required to comply with these Mandatory Requirements should ensure that the Business Unit, on whose behalf the processes are being performed, is able to comply with the obligations of the Group Payments Policy. The Group Payments Policy Supplier Version Requirements are as follows: 2.1 POLICY AND REGULATORY ENVIRONMENT a) Where this Policy has a requirement greater than local law, all parties must adhere to this Policy. b) Where local law, including court orders, contradicts the Policy, local law takes precedence. Any instances of this must be documented in the annual attestation. c) All parties must adhere to Payment Scheme membership rules and regulations, where a party is a member. d) All parties must consider whether they are in scope of the Payment Services Regulations. Where a party determines that they are in scope, they must ensure compliance to relevant requirements. e) All parties must include full originator information and required beneficiary information in all fund transfers and related messages or instructions created on behalf of the Group s customers or the Group. Where it is available full beneficiary address should also be included. This information must remain throughout the Payment chain. f) All parties must review the SEPA Regulation (EU260/12) and consider whether they are in scope. Where a party determines that they are in scope, they must ensure compliance to relevant requirements. 2.2 CUSTOMER INSTRUCTIONS a) The customer must be identified through a process which proves that an individual or an entity is who they say they are and reside where they say they do before a customer instruction is processed. b) Evidence that the checks in 2.2a have been completed must be maintained. c) The customer s instruction must comply with the product or account authority/mandate and any other authorities or procedures applicable to the account. d) For payments initiated, or processed in any other way, by the third party on behalf of the Group and not by a customer instruction, processes must be in place to ensure that the payment is being made to a known Third Party and is not fraudulent. e) Under no circumstances should information in a payment instruction be omitted, deleted or altered; both manual processes and systems should be designed to prevent this from happening. 2.3 PAYMENTS OPERATIONAL PROCESSING a) Payment instructions must comply with the requirements in Section 2.2 CUSTOMER INSTRUCTIONS above, and must not be processed unless those requirements have been met. Page 2 of 7

3 b) A full audit trail must be maintained of the payments processes performed by the Third Party on behalf of the Business Unit. c) In respect of each payment, all parties must meet at least one of the following before a payment is made: i. Segregation of duties (also known as four or six eye scrutiny) and/or dual control between the input, check and release of payments must be in place. ii. Where segregation of duties or dual control under i. (above) is not possible the business must have a documented process post payment control and quality checking that is at least as robust as segregation of duties and fulfils the same aim. Quality checking, dip testing and/or monitoring must be undertaken based on a statistically significant volume of payments. d) All parties must give colleagues documented parameters for the types of work they are authorised to complete; for example, release payments up to a certain value. Controls must be in place to ensure adherence. e) All parties must define and document their fraud check thresholds. Controls must be in place to ensure adherence. f) Under no circumstances should information in a payment instruction be omitted, deleted or altered; both manual processes and systems should be designed to prevent this from happening. g) Where a payment requires repair, documented processes must be in place and the repaired instruction must be treated as a new request and be checked appropriately. 2.4 PAYMENT ROUTING All Payment instructions must meet SWIFT standards and formatting. Where this is the case, all parties must use SWIFT as the access channel for routing the Payment instruction. a) Payments through SWIFT may only be effected through the appropriate authenticated message type. b) Only channels which protect the integrity and confidentiality of the Payment instruction or data may be used. 2.5 RECONCILIATION AND REPORTING a) All operational accounts must form part of an account landscape which is clearly documented, and validated and evidences key ownership and accountability b) Every account that is reconciled must have a defined usage description and documented account matching criteria, write off limits and exception handling and loss sign off procedures. c) A documented process must exist which provides step-by-step procedures on how to perform the account reconciliation process d) Aged analysis must take place on each account to ensure the control of older outstanding items. e) All accounts reconciled or monitored must have a clearly documented monitoring and surveillance process. This should detail how monitoring is executed for both experienced and new to role colleagues. Evidence of the monitoring having taken place should be maintained. f) If parties are required to complete specific reporting of financial information on account balances, either internally or to external bodies, these requirements must be clearly documented and adherence evidenced. 2.6 PAYMENTS AND CUSTOMER SCREENING a) All Payments must be screened in line with a documented; risk focused in Page 3 of 7

4 flight payment screening process to identify Payments to prohibited individuals and entities under local Sanctions legislation. b) Account/customer relationship screening must be in place to identify prohibited individuals and entities under local Sanctions legislation. c) Processes must be in place to investigate and distinguish any matches identified due to the screening in 2.6a and 2.6b. from individuals and entities with similar names. Where there are insufficient identifiers (e.g. date of birth, nationality etc.) a risk based approach must be adopted and potential matches are investigated in a timely manner. The results of all investigations must be documented, identifiable, legible and capable of being retrieved in a timely manner. d) Customer screening must be place to identify Politically Exposed Persons (PEPs). Screening must include new to bank relationships as well as existing relationships which may become categorised as a PEP e) Once a PEP is identified the rationale for commencing, continuing or terminating a relationship with the PEP must be clearly documented in light of the increased risks of relationships with PEPs. This rationale be reviewed on a regular basis. MANDATORY REQUIREMENTS NON-COMPLIANCE Any non compliance with this policy should be escalated to the Payments Officer of the Business Unit that owns the relationship. The Payments Officer is responsible for raising the non compliance within Third Party Suppliers through the waiver and breach processes outlined in the Group Payments Policy document. APPENDICIES Appendix A Attestation Document PLEASE COMPLETE AND DOCUMENT TO GRPG5592@lloydsbanking.com PLEASE NOTE THAT THIS DOCUMENT MUST BE SIGNED OFF BY THE PAYMENTS OFFICER OF THE RELATIONSHIP OWNING BUSINESS UNIT BEFORE SUBMISSION Page 4 of 7

5 Document Purpose: The purpose of this document is to provide a uniform template for conducting an attestation whereby Supplier Managers can work with Third Party Suppliers to determine and report on their compliance against each section of the supplier version of the Group Payments Policy. This document aims to provide a summary of the high level rationale behind any Gaps behind current levels and expected levels of compliance for each third party Supplier. Completing the Document: * Denotes Mandatory Field 1* Complete 'Business Unit Background' tab by providing Business Unit Details and confirm that supporting documents are attached to the submission 2* Where compliance is not met a waiver or breach must be raised Completing Individual Policy / Standard Section Tabs * Denotes Mandatory Field 1* Please provide details on the Business Unit for which the Gap analysis is being completed. 2* Compliance Rating: Please select the option that best describes the current situation of the Business Unit in regards to compliance with the specific Policy / Standard section noted at the top of the tab. - Fully Compliant: The Business Unit is 100% compliant with the associated Policy / Standard section. - Partially Compliant The Business Unit complies with some aspects of the Policy sections and standards. - Not Compliant The Business Unit complies with no aspects of the Policy section and standards - Not Applicable The Business Unit does not perform any activities which are covered by this section of the policy 3* Rationale: Please provide the reasoning behind the selection of the 'Compliance Rating'. Where possible provide details on how the specific Policy / Standard section relates to the Business Unit and how the selected level of compliance is achieved within the Business Unit. e.g. In general terms there is an adequate segregation of duties and controls within the payment processing team. However, two factor authentication for Internet Banking is not in place. Nevertheless, there are enough mitigating controls in place in order to avoid fraudulent activity. The customer has to input 2 different passwords in order to access Internet Banking site. In addition transfers can only be made to a pre-registered route. No free format transfers are allowed. No fraud event in Internet Banking has ever happened. 4* Waiver Submitted? Where a 'Compliance Rating' is Partially Compliant or Not Compliant, please confirm a waiver has been submitted by the Business Unit, on whose behalf the processes are being performed on RuleSafe Page 5 of 7

6 Business Unit Background The purpose of this section is to provide context and evidence to support your attestation against the Group Payments Policy Supplier version. Please note that all fields are mandatory. Third Party Supplier Name: Relationship owning Business Unit: Division: Payments Officer of Relationship Owning Business Unit: Form Completed by: Supplier Manager in Relationship Owning Business Unit: Key Contact from Third Party responsible for liaising with Business Unit: Form Reviewed by (Business Unit Control Function of the Relationship Owning Business Unit): Description Supplier s goods or services provided to Relationship Owning Business Unit: Please give a brief description of the activities performed by the supplier Types of Payment Processed: Please list all types of Payments which are made (e.g. CHAPS, BACS, SWIFT etc.) Annual Payments Value and Volume: State the value and volume of Payments Documentation Payments Processing Flow Chart: Please attach a document containing a flow chart which illustrates: - the Payments process within the Business unit - the IT systems and applications and - any hand offs to internal and external third parties File Name Standard Attested Against Policy & 2.1 Regulatory Env ironment Customer 2.2 Instruction Payments 2.3 Operational Processing 2.4 Payment Compliance Rating (See key below) Rationale If not applicable please state where you hand off to Waiv er Submitted? Page 6 of 7

7 Routing Reconciliation & Reporting Payments and Customer Screening Not Compliant Partially Compliant Fully Compliant Not Applicable KEY - Attestation Rating Not compliant to the w hole sub-standard Compliance to the core Standards and any of the sub- Standards contained w ithin is not fully effective. Compliant to the w hole sub-standard Standard not applicable to BU functions (Rationale must be provided) Version Number Effective Date FINAL v1.0 01/04/ /10/ /08/ /10/2017 Next Planned Revision: January 2018 Page 7 of 7