Reliance authentication

From Wikipedia, the free encyclopedia

Reliance Authentication

Reliance authentication is process whereby a second entity relies upon the authentication processes put in place by a first entity. The second entity creates a further element that is unique and specific to its purpose, that can only be retrieved or accessed by the authentication processes of the first entity having first being met.

Reliance authentication can be achieved by a single or plurality of tokens with random characteristics being transmitted to a secure area controlled by the first entity, where such secure area is only accessible by the person authorised to use the account. The secure area may be an online banking portal, telephone banking system or mobile banking application.

The token is often in the form of a single or plurality of debit or credits to a financial account, where the numerical values of the debit or credits form the token, whose numeric value is to be confirmed by the account holder.

The token(s) are retrieved by the cardholder accessing a secure area from the 1st entity's secure area, which is protected and accessible only by satisfying the 1st entity's authentication means. In the case of financial services, authentication to access the secure area normally includes multi-factor and in the SEPA would likely involve Strong authentication.

The transmission and requirement to retrieve the token(s) adds a further challenge and response factor to the overall authentication process, when considered from the point of view of the 2nd party, which generates and transmits the tokens.

The token(s) may be generated by the 2nd party dynamically, and can thus act as one time password(s).

The reliance authentication method has particular application with financial instruments such as credit cards, e-mandate and direct debit transactions, whereby a person may instigate a transaction on a financial instrument, however the financial instrument is not verified as belonging to that person until that person confirms the value of the token.

The reliance method often incorporates an out of band response means, once the tokens have been retrieved from the secure area.

Legal Basis

The introduction of Strong Customer Authentication [1] for online payment transactions within the European Union and SEPA now links a verified person to an account, where such person has been identified in accordance with statutory requirements prior to account being opened. Reliance authentication makes use of pre-existing accounts, to piggy back further services upon those accounts, providing that the original source is 'reliable'.

The concept of reliability is a legal one derived from various Anti Money Laundering (AML) / Counter Terrorism Funding (CTF) legislation in the USA,[2] EU28,[3] Australia,[4] Singapore and New Zealand[5] where second parties may place reliance on the customer due diligence process of the first party, where the first party is say a financial institution.

In the Australian legislation, 'reliance' is based upon section 38 of the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (Cth).

In the European Commission's Proposal for a DIRECTIVE OF THE EUROPEAN PARLIAMENT AND OF THE COUNCIL on the prevention of the use of the financial system for the purpose of money laundering and terrorist financing, reliance is based upon Article 11(1)(a).

Reliance in the UK has a very specific meaning and relates to the process under Regulation 17 of the Money Laundering Regulations 2007. "Reliance" for the purpose of AML and "reliance authentication" are not the same, although both use similar concepts.

The Federal Financial Institutions Examination Council of the United States of America (FFIEC) issued "Authentication in an Internet Banking Environment", dated October 2005. Reliance authentication is outlined per the final paragraph of page 14.

Advantages

Advantages of reliance authentication methods are:

  • when used in conjunction with financial services, the identity of the customer has been verified in accordance with AML/CTF legal requirements upon original account having been opened.
  • they reuse existing security that is already maintained (e.g. by financial institutions).
  • they use familiar and trusted sources. Accessing a financial account in order to retrieve the tokens (which are either credits or debits) is a familiar process to the account holder, and is often available via a variety of means including mobile, online, telephone banking and ATM access.
  • both processes use an in band method to transmit the tokens, with an out of band response mechanism whereby the account holder re-keys in the token value to a new mobile, webpage or .app. This mitigates man in the middle and boy in the browser attacks with regards to the token being intercepted.
  • they are a software solution, not requiring any additional hard tokens or complex integrations. Tokens are transmitted as part of the financial network, without the need for any dedicated new networks.
  • that they can be implemented without the involvement of the account issuing institution.

See also

References

  1. ↑ http://www.ecb.europa.eu/press/pr/date/2013/html/pr130131_1.en.html
  2. ↑ http://www.ffiec.gov/pdf/bsa_aml_examination_manual2006.pdf
  3. ↑ http://eur-lex.europa.eu/LexUriServ/LexUriServ.do?uri=CELEX:52013PC0045:EN:NOT
  4. ↑ http://www.comlaw.gov.au/Details/C2013C00371
  5. ↑ http://www.dia.govt.nz/diawebsite.nsf/wpg_URL/Services-Anti-Money-Laundering-AMLCFT-Act-and-Regulations


This article is issued from Wikipedia. The text is available under the Creative Commons Attribution/Share Alike; additional terms may apply for the media files.