Forum Forums Opening a Bank Account: Cross Border Identity Bank liabilities when using a digital identity from a government identity scheme

Viewing 1 post (of 1 total)
  • Author
  • Harry Weber Brown
    Post count: 1

    Bank liabilities when accepting a digital identity from a government identity scheme
    The OIX Connecting Europe Facility (CEF) project is investigating a model under which a prospective customer of a bank in another country could use the digital identity from a digital identity scheme notified by a member state under the eIDAS framework , as a means of verifying identity details, during the application process. The project is using the example of a French citizen opening a bank account in the UK with their France Connect eID. In order to limit complexities it has been decided that credit products are out of scope for this project.

    This paper considers the generic risks to a bank when opening a bank account with a new customer, the potential liabilities that the bank is exposed to in the process and how these liabilities are managed by abank.

    It then describes the process proposed by the CEF project, and considers the functionalities necessary for the process to be operationally feasible and the liabilities of the various parties involved.

    Risks to a bank when opening an account with a new customer
    Banks face risks when opening a new customer relationship. For the purposes of this document there are three categories of risk to be considered:

    ● Credit risk; that the (honest) customer is not able to repay any loans that he / she is provided by the bank. [However, credit products and how a bank manages credit risk are not considered within the scope of this project.]
    ● Fraud risk; that the customer supplies false information (including identity details) and is able to commit either:
    ○ 1) First party fraud – whereby the individual defrauds the bank
    ○ 2) 3rd party fraud – whereby the individual creates a mule account. This may use a real identity, but the purpose of the account is to defraud other people.
    ● Legal risk; the risk of loss or imposition of penalties, damages or fines from the failure of the firm to meet its legal obligations including regulatory or contractual requirements.
    ● Operational risk; the risk that the bank has inadequate or failed processes in place e.g. for managing personal data.

    If a bank fails to correctly mitigate the above risks associated with identifying potential customers, then this may result in fines, paying damages, being defrauded and reputational damage. On the other hand, if a bank’s processes are far too difficult for people to meet, resulting in a significant number of real, honest people being turned down, this then this may result in them turning away potentially profitable custom which is not viable in the long term.

    Bank liabilities differ in each of the risk scenarios above. A bank will have mechanisms to mitigate the risks:

    1. Develop internal operational processes that manage the risk cost effectively by acquiring information about the customer and his / her transactions and by validating this information with independent and reliable sources.
    2. If a bank isn’t able to acquire sufficient information to satisfy its processes, either from the customer or from other sources, then the bank will no longer proceed with the account opening.

    Risks associated with identity verification
    The bank must establish confidence about the identity of the Prospective Customer as, without this it is not possible to validate the assertions that he or she makes about the context for the new banking relationship and any relevant personal information.

    There are two principle types of identity fraud:

    ● Identity ‘theft’ where a fraudster impersonates another person
    ● Identity fabrication where a fraudster establishes a new or amended set of identity details

    To mitigate the risks of identity fraud the bank must assure itself to an appropriate level of certainty that:

    ● The identity details asserted by the Prospective Customer can be corroborated against independent and reliable sources so as to confirm that they describe a ‘real’ person
    ● That the identity details have not been reported as being associated with identity fraud.
    ● That the identity is a ‘developed identity’ i.e. the evidence for the identity does not appear to have originated at a specific point in time indicating an abnormal existence.
    ● That the person asserting the identity details can demonstrate that he / she is the person described by the identity.

    Traditionally, these mitigations are performed by inspecting paper documents such as passports, driving licences and utility bills or by checking the personal data asserted by the Prospective Customer with independent and reliable sources

    Currently there are no Europe-wide standards for the financial sector describing the level to which identity assurance should be achieved. Instead, a risk-based approach applies: banks are obliged to ensure that the level of Customer Due Diligence is proportionate to the context of the business transacted by the bank. Additionally, some countries may have ‘national guidance’, for example in the UK the Joint Money Laundering Steering Group (JMLSG) provides guidance around the interpretation of Money Laundering directives. Across Europe the nature of the national guidance varies with some countries having more detailed guidance than others, creating a lack of consistency in the application of Money Laundering regulations.

    Bank liabilities today
    The liability of a bank in any given scenario is dependent on the circumstances in which a party seeks redress. For example, if a payment scheme has been then the protections of the different parties will vary between a Direct Debit and a push payment based upon the rules of the scheme.

    Where a party seeks redress from a bank then the question that is asked is, essentially, did the bank do the right thing. Part of the judgement test may consider whether the account was opened using documents and identity verification processes that are compliant with regulatory requirements and industry best practice.

    The models for identity verification permitted in the UK under current HM Treasury industry Guidance are:

    ● the bank requests particular documents to be presented by the customer, tests that the documents are genuine and keeps a copy of them
    ● the bank asks a Credit Reference Agency to give it data which it uses to determine whether the identity assertions of the customer are valid
    ● the bank places reliance on a third party – which does the end to end identity verification process. The bank tests the third party for compliance on a regular basis.

    In each model liability for the identity verification process resides with the bank. All banks accept government issued documents, such as a passport or driving licence, as a proof of identity and / or address but the government suffers no liability if the document has been issued to a fraudulent identity and then used to open an account for illegal purposes.

    It is possible to investigate fraudulent identity details that have come to light within a country but not, at present, across borders. Identity fraud data is shared between organisations within the UK, but not across Europe.

    Where a bank has determined there to be a breach with regard to an identity document then the bank would be considered to be on notice and hence in a position of ‘constructive trust’ making the bank liable for related third party losses that might arise.

    Management of liabilities today
    Bank liabilities are managed through risk models that depend upon information about the customer. Without high assurance of the identity details it is difficult for the bank to have confidence in the data about the customer.

    Banks therefore mitigate the risks from identity verification in proportion to their liabilities associated with the business transacted with the customer.

    Liability to regulators for compliance with money laundering regulations
    Banks minimise their legal risks through internal processes agreed with regulators. As criminals become more sophisticated, the Customer Due Diligence regime for banks becomes more stringent, for on-boarding of new customers, for monitoring of existing customer relationships and for monitoring the counterparties of the banks’ customers. In recent years banks around the world have incurred penalties from regulators, even in cases where no fraud has occured but bank Customer Due Diligence processes have been shown to be inappropriate.

    Liability for losses to the bank
    Banks will minimise their exposure to losses from either:

    ● bad debt; by collating sufficient quality information about the customer’s circumstances and business transactions to model the risk of exposure to loss to the bank and price the risk accordingly
    ● fraud; by validating information about the customer and the customer’s circumstances was insufficient to detect the likelihood of loss.

    Liability to the bank’s customer
    In some circumstances, banks will be liable to their customers for losses incurred. Banks manage the risks of loss through clarity of the contractual responsibility between customer and bank and by investment in internal operational capabilities to detect fraudulent transactions.

    Liability to third parties
    In some circumstances, banks will be liable to third parties for losses incurred through fraud. [Give an example.]

    Liabilities passed by the bank to third parties
    Where banks use the services of third parties there may be contractual terms that pass some liabilities to the service provider. For example, where identity information is being passed through an infrastructure from the source of evidence to the relying party bank, then there is a risk of ‘man in the middle’ attack. The contractual terms may pass liability in the event of such an attack onto the infrastructure supplier. However, the conditions of the liability will be clearly defined and capped.
    Process proposed through the CEF project
    The user experience for opening a generic bank account in another country proposed under the CEF project is described through a set of wireframes. The diagram below describes how the applicant’s identity and associated personal data is relayed to the bank.

    1. The bank invites the Prospective Customer to verify his or her identity digitally through an Identity Provider that is recognised under the eIDAS regulation
    2. The Prospective Customer navigates to his / her national Identity Provider and authenticates using the Identity Provider’s credentials.
    3. The Identity Provider requests permission from the Prospective Customer to pass to the bank his / her identity details and any additional personal data requested by the bank.
    4. The bank receives the identity details and additional personal data through the eIDAS compliant infrastructure and populates the Prospective Customer’s application form with them.
    Changes to bank liabilities under the process proposed
    In the context of banking and the Money Laundering Regulations discussed in this document it is not envisaged that banks liabilities would change under the model proposed through the CEF project. [The EU General Data Protection Regulation has liability implications for organisations of all types. These are not considered within this document.]

    The commercial market for digital identities that meet government standards will vary from one country to another. In markets where a public sector entity is responsible for the digital identity and the infrastructure through which it is asserted, it is unlikely that the public sector Identity Provider will accept any liability should the identity prove to have been inaccurately or fraudulently asserted to the bank. For these countries the market will appraise the risks of identity fraud on a country by country basis.

    In markets where private sector Identity Providers are certified as able to make identity assertions on behalf of a person according to government standards then it is anticipated that the commercial contract between the Identity Provider and the bank will require the Identity Provider to take a clearly defined liability in specific circumstances, for example where the defined standards and processes have not been met. However, although this may cover bank financial losses it will not remove ultimate liability from the bank.

    For a federated digital identity scheme such as the one proposed in the CEF project to be adopted there will need to be a mechanism for sharing identity fraud data. If a digital identity is discovered to be fraudulent there must be a mechanism to revoke it and alert those organisations that may have been exposed to fraud as a result.

    Benefits to banks under the process proposed
    The European Commission has agreed wording in the 5th Money Laundering Directive that recognises digital identities under the eIDAS framework. To date it is not known how this change will transpose into national law and national guidance. However, this regulatory change will provide confidence to banks to explore the operational practicalities of digital identity schemes.

    Notwithstanding current regulations, for banks there is a need to enable new and existing customers to transact and assert personal and identity information through digital channels. Traditional physical documents are more easily spoofed by sophisticated fraudsters and face-to-face interactions in branch are becoming less common. New services and technologies make it quicker, easier and potentially more secure for customers to access financial services digitally and a range of new market entrants are leveraging these.

    The principal benefits for banks in adopting a digital identity scheme that meets internationally recognised government standards will be:

    ● That the bank can have greater confidence in the accuracy and currency of the identity details of the customer him or herself thereby reducing potential fraud and demonstrably complying with identity verification requirements for Customer Due Diligence
    ● That the bank can assess information about the customer in terms of the government identity verification standards and develop more automated and less subjective methods of assessing data, as explained in the section on Attribute Linking below
    ● That remote account opening will be dependent upon a universal digital identity scheme and not on a credit footprint which excludes some customer demographics
    ● That it facilitates the creation of a truly European market for financial services .

    Attribute Linking
    In meeting Customer Due Diligence requirements banks are obliged to gather and monitor information about their customers. For example, the customer’s current residential address is an example of an attribute of information that most banks require from their customers.

    In some, but not all national digital identity schemes the customer’s current residential address may be available from the Identity Provider. In such circumstances the bank can be assured that the current residential address will have been verified to a consistent standard as the name and date of birth of the customer.

    In some countries the current residential address is maintained by a separate public sector scheme. The national digital identity system may be used by the person to give consent to sharing of the address with the bank. Depending on the rules under which the public sector scheme requires that current residential address must be updated by the citizen the bank can assess the likelihood of its inaccuracy.

    In other countries the customer may use a third party source as evidence of current residential address, for example a utility bill. The bank can then assess:

    ● How the utility company that issued the bill verified the identity of the customer to whom the bill was issued
    ● How current the information is likely to be; a utility billing system may have been set up several years ago
    ● How secure the mechanism of assertion of customer’s residential address is in the current context is.

    A standardised framework can be developed to assess the trustworthiness of the attributes asserted by the customer based on the source against which they have been validated. Data about the attributes, so called ‘metadata’ can be defined using the same definitional framework as established in the eIDAS identity verification standards. This would allow the attributes to be appraised in terms of:

    ● how the source for the attribute verified the identity of the person at registration
    ● how the attribute itself was validated
    ● when the attribute was last validated
    ● how the digital identity in the current transaction has been verified by the source and associated to the attribute.

    Based on such a system of metadata, a bank could achieve a high degree of automation both in processing information received from the customer and in scheduling when to review information based on risk.

    A similar approach could be applied to other data that has not been asserted by the customer but checked independently, such a listings for Politically Exposed Persons and those to whom sanctions apply.
    A system that enables people to use their certified digital identity scheme would provide many advantages to banks, reducing fraud and enabling automation and improved customer service. It would not change the bank’s liabilities however it would mitigate a number of risks for a bank.

    However, a number of additional features of such a scheme will be required if it is to be become operational and deliver its potential benefits:

    ● a contractual framework describing the responsibilities of each party in various circumstances
    ● a system for detecting and alerting participants when fraud is detected
    ● a metadata framework by which each Relying Party can assess the trustworthiness of attributes it receives associated to the digital identity.

    Annex: reference material

    Purpose: The points below draw out material currently available on liability models under eIDAS and GOV. UK Verify to provide examples of how liability is handled under these models. The purpose is to illustrate possibilities, but not to provide limitation on how liability should be addressed under the private sector cross border model.

    1. The report Digital identity across Borders: Opening a Bank Account in Another EU Country notes the following on the liability:
    ‘The eIDAS Regulation includes provisions on liability for notifying Member States, which private sector service providers could consider when starting to look at when relying upon digital identities under notified schemes. It does not address some of the other questions which need to be handled, such as the question of commercial models – where it makes identification and authentication free to a service online provided by a public sector body, but leaves to Member States how they establish the regime applicable to the private sector.
    The eIDAS Regulation, Article 11 describes the liability model, and is included below:

    Article 11- Liability
    1. The notifying Member State shall be liable for damage caused intentionally or negligently to any natural or legal person due to a failure to comply with its obligations under points (d) and (f) of Article 7 in a cross-border transaction.
    2. The party issuing the electronic identification means shall be liable for damage caused intentionally or negligently to any natural or legal person due to a failure to comply with the obligation referred to in point (e) of Article 7 in a cross- border transaction.
    3. The party operating the authentication procedure shall be liable for damage caused intentionally or negligently to any natural or legal person due to a failure to ensure the correct operation of the authentication referred to in point (f) of Article 7 in a cross-border transaction.
    4. Paragraphs 1, 2 and 3 shall be applied in accordance with national rules on liability.
    5. Paragraphs 1, 2 and 3 are without prejudice to the liability under national law of parties to a transaction in which electronic identification means falling under the electronic identification scheme notified pursuant to Article 9(1) are used.

    References in Article 11:
    Article 7 – Eligibility for notification of electronic identification schemes
    (d) the notifying Member State ensures that the person identification data uniquely representing the person in question is attributed, in accordance with the technical specifications, standards and procedures for the relevant assurance level set out in the implementing act referred to in Article 8(3), to the natural or legal person referred to in point 1 of Article 3 at the time the electronic identification means under that scheme is issued;

    (e) the party issuing the electronic identification means under that scheme ensures that the electronic identification means is attributed to the person referred to in point (d) of this Article in accordance with the technical specifications, standards and procedures for the relevant assurance level set out in the implementing act referred to in Article 8(3);

    (f) the notifying Member State ensures the availability of authentication online, so that any relying party established in the territory of another Member State is able to confirm the person identification data received in electronic form.
    For relying parties other than public sector bodies the notifying Member State may define terms of access to that authentication. The cross-border authentication shall be provided free of charge when it is carried out in relation to a service online provided by a public sector body.
    Member States shall not impose any specific disproportionate technical requirements on relying parties intending to carry out such authentication, where such requirements prevent or significantly impede the interoperability of the notified electronic identification schemes;

    Article 9 – Notification
    1. The notifying Member State shall notify to the Commission the following information and, without undue delay, any subsequent changes thereto:
    (a) a description of the electronic identification scheme, including its assurance levels and the issuer or issuers of electronic identification means under the scheme;
    (b) the applicable supervisory regime and information on the liability regime with respect to the following:
    (i) the party issuing the electronic identification means; and
    (ii) the party operating the authentication procedure;
    (c) the authority or authorities responsible for the electronic identification scheme;
    (d) information on the entity or entities which manage the registration of the unique person identification data;
    (e) a description of how the requirements set out in the implementing acts referred to in Article 12(8) are met;
    (f) a description of the authentication referred to in point (f) of Article 7;
    (g) arrangements for suspension or revocation of either the notified electronic identification scheme or authentication or the compromised parts concerned.

    2. The GOV.UK Verify scheme includes the following elements in its framework on liability , which are summarised in Executive Summary of Identity Assurance Provider Framework Agreement 2.

    The Verify scheme
    1. There may need to be an additional clause built in to 59 to guard against any privacy breach will does not currently fall within the ambit of personal injury;
    2. There are three separate subsets of risk and liability:
    i). That exposure and liability for a breach of privacy, mental anguish, bodily injury or other tortious damages to users arising out of a breach (where the Framework Agreement and the Assurance Standards have not been adhered to);
    ii). That breach of contract between providers, where the Assurance Standards have been adhered to;
    iii).That breach of contract between providers, where the Assurance Standards have not been adhered to;
    iv). That liability for a breach of privacy, mental anguish, bodily injury or other tortious damages to users arising out of a breach of contractual duty (where the Framework Agreement and the Assurance Standards have been adhered to);
    3. Insurance should properly take all of the liabilities -regardless of relative liability of the respective Providers – under ii).and iv).
    4. The more clear cut breach of contractual duties between the same parties should be left within the contracts and should be liquidated damages, agreed and set by the parties within the Identity Assurance Provider Framework Agreement. Rather than have this left otherwise to mediation, the parties must agree to use a determination mechanism whereby assurance is governed by independent arbiters on security (such as QinetiQ, BAE), contractual breaches (Slaughter & May, if they constructed the original agreement) and authentication (there are a number that can be used);
    5. To allow for a broader set of tortious liabilities and exposures (there is a very clear demarcation of the two which the insurance framework will enable to be transferred away from the Providers and GOV.UK), the risk pool will be created with Lloyd’s and redistributed via capital markets and an ILS mechanism. This will also provide a launchpad for the UK Government’s stated objectives in establishing a UK ILS market.;
    6. Clause 59 will have to be expanded so that all appropriate and relevant security, data breach and privacy considerations are included. Also, “loss or damage to property” will have to be expanded, just as the nomenclature of “default” will have to be broadened and refined;
    7. Clauses 60 and 61 will have to be amended in light of the points above, but particularly in relation to 7. Above.
    8. The intent behind 62. is clear, but this will have to be broadened, replicated within the Provider’s contracts and appropriately mirrored in the insurance risk transfer/coverage;
    9. I need some better understanding of the intent behind 64; some aspect of this will be transferred into the insurance mechanism;
    10. Insurance must be mandatory and be made part of the Framework so that all friction and conflict is removed between the respective Parties.


    59. The Provider indemnifies the Authority against all Losses arising from:
    ● Provider fraud;
    ● breach by the Provider of the licence to use the GOV.UK Certified Logo;
    ● breach of cyber security provisions;
    ● death or personal injury; or
    ● loss or damage to property caused by Provider default.
    60. Indemnities a – d above are uncapped. The Provider’s aggregate liability in respect of loss or damage to property (including indemnity e above) caused by Provider’s default is no more that £10 million in any rolling period of 12 months.
    61. Outside the types of loss mentioned above, any other Provider liability for breach is on a normal contractual basis, not a pound for pound indemnity. The Provider’s aggregate liability in this respect is no more in any rolling period of 12 months than the higher of £7.5 million or 150% of the Charges payable in that same rolling 12 month period.
    62. If any breach is fraudulent or wilful (i.e. on purpose, not accidental or negligent) then the Provider’s liability is uncapped.
    63. The Provider is not liable for loss of profit of the Authority, but it is liable for specified types of losses, including wasted expenditure and compensation paid to third parties by the Authority and/or other government bodies.
    64. The Provider will not be in breach of the agreement (and therefore will not be liable) solely because a Private Sector Attribute Provider provides faulty information (except to the extent that the Provider itself recovers compensation from the Private Sector Attribute Provider or the Private Sector Attribute Provider is in the same Group as the Provider), so long as it has complied with the general requirements relating to such parties (see below).
    65. The Provider, as the indemnifying party, will have some control over conduct of claims.
    66. The Provider is required to take out insurance, on a basis to be set out in the Framework Agreement.

    Questions to consider
    1. Who buys insurance?
    2. How do they buy insurance, ie at which stage of signing contracts?
    3. Which insurance contracts are standardised for Verify and which are generic?

Viewing 1 post (of 1 total)

You must be logged in to reply to this topic.