Financial Profile

Full Title or Meme

A profile of the Identity Ecosystem Framework Profiles for Financial Services

Context

• As a part of the creation of a set of Identity Ecosystems this profile is targeted to apply to any transaction that puts a user's financial assets at risk.
• The most fully developed profiles are now in development in Europe, especially the UK Open Banking effort. Those have been consulted in creating this profile.
• Because of strong regulations in all jurisdictions for financial transaction, there will be some "Financial Authority" in each jurisdiction which will determine the appropriate Identifiers for Financial Institutions, and perhaps for customers as well.
• The FSSCC profile of the NIST cyber-security framework should serve as both a source of security assurance as well as a paradigm of federated frameworks that we could use in our framework design.

Problems

• Each jurisdiction creates their own Identifier domain for financial services and for the users of financial services, many of which are legal persons, but not natural persons.
• In all cases that are known in 2018, a natural person is required to take responsibility for the financial institution (FI) or other money handling organization for regulatory reasons.
• Customers (or account holders or subjects) in a financial transaction need to be identifiable to money laundering governmental agencies, for example Fincen in the US. This "know your customer (KYC)" requirement puts special meaning on the validation of the subject, but that is normally the responsibility for the FI. If both the sender and the receiver of financial assets are FIs, then both are responsible to to know the customer. Some jurisdictions may place a burden on any recipient, and the Financial authority would need to recognize that requirement.
• Providers in a Financial transactions (basically banks and payment initiators) need to be well-known to the Financial authority

1. Certificate Issuance and Verification from UK Open banking -- Key to the authentication and identity characteristics of TLS is the issuance and verification of certificates. There are a number of different approaches that can be applied to financial APIs - each with a different trust model.
   1. Standard website certificates issued by globally trusted certificate authorities trusted by the browser source. These standard "domain validated" certificates provide no authoritative identity assurances themselves, but are often times sufficient when the client has other means of confirming the identity of the financial API provider. It is possible for a provider to obtain an "extended validation" certificate which does provide assurance of the corporate identity of the provider. In practice these provide little additional benefit as the client will still need to make a decision based on external criteria as to whether they trust the API provider. One downside with this approach is that it is harder to use client certificates from the same certificate authorities as few of them will issue such certificates.
   2. Regional trust frameworks, such as eIDAS in the EU -- The eIDAS family of legislation in the EU provides a trust framework with qualified trust service providers. These service providers can issue both server and client certificates and there are various standards to support additional metadata in such certificates, such as the regulatory status of the owner of the certificate. For region specific deployments this approach may be of merit. Moreover such certificates have a clear and strong legal status and in some cases are mandated to be used by law.
   3. Federation Operators -- Some ecosystems, particularly closed ecosystems, delegate the responsibility for issuing certificates to a federation operator. This entity will have the responsibility for verifying the identity of the participants according to rules specific to the federation. Each participant in the ecosystem will trust the federation operator and may well have a specific contract or terms of service in place with such an operator. Examples of this approach in the UK are the UK Open Banking Directory and the Origo Unipass system.

Solutions

• PSD2 and the Berlin Group are creating standards for Euro currency countries.
• UK open banking effort well along the way to establish criteria for exchanging financial information and instructions.
• FSISAC
• ISO TC-68 has begun
• Australian standard looks like FAPI, but may be more broadly targeted.

References

• The page Financial Profile Sandbox details a test suite that will allow developers of code and user experience to assure the compliance of their products to the framework.
• The OpenID federation is currently in development of Financial-grade API specifications which have been consulted. Since they do not actually require a user Identifier they are of limited value. Also the last time that web page was accessed it was out-of-date.