(a) Requirement to maintain interfaces. A data provider subject to the requirements of this part must maintain a consumer interface and a developer interface. The consumer interface and the developer interface must satisfy the requirements set forth in this section. The developer interface must satisfy the additional requirements set forth in § 1033.311.

(b) Machine-readable files upon request. Upon request for covered data in a machine-readable file, and subject to paragraphs (b)(1) and (2) of this section, a data provider must make available to a consumer or an authorized third party covered data in a file that is machine-readable and that the consumer or authorized third party can retain and transfer for processing into a separate information system that is reasonably available to and in the control of the consumer or authorized third party.

(1) Consumer interface. With respect to covered data provided through its consumer interface, a data provider is not required to comply with:

(i) The requirements of this paragraph (b) for the covered data described in § 1033.211(c) (payment initiation information) and (f) (account verification information); and

(ii) The requirement of this paragraph (b) to provide in a file that is machine-readable the covered data described in § 1033.211(d) (terms and conditions).

(2) Developer interface. With respect to covered data provided through its developer interface, a data provider satisfies the requirements of this paragraph (b) if it makes available covered data in a form that satisfies the requirements of § 1033.311(b).

(c) Fees prohibited. A data provider must not impose any fees or charges on a consumer or an authorized third party in connection with:

(1) Interfaces. Establishing or maintaining the interfaces required by paragraph (a) of this section; or

(2) Requests. Receiving requests or making available covered data in response to requests as required by this part.

(a) General. A developer interface required by § 1033.301(a) must satisfy the requirements set forth in this section.

(b) Standardized format. The developer interface must make available covered data in a standardized and machine-readable format. Indicia that the format satisfies this requirement include that it conforms to a consensus standard.

(1) Meaning of format. For purposes of this section, format includes structures and definitions of covered data and requirements and protocols for communicating requests and responses for covered data.

(2) Meaning of standardized. For purposes of this section, standardized means conforms to a format widely used by other data providers and designed to be readily usable by authorized third parties.

(c) Commercially reasonable performance. A developer interface's performance must be commercially reasonable.

(1) Response rate; quantitative minimum performance specification. The performance of the interface cannot be commercially reasonable if it does not meet the following quantitative minimum performance specification regarding its response rate: The number of proper responses by the interface divided by the total number of requests for covered data to the interface must be equal to or greater than 99.5 percent in each calendar month. For purposes of this paragraph (c)(1), all of the following requirements apply:

(i) Any responses by and requests to the interface during scheduled downtime for the interface must be excluded respectively from the numerator and the denominator of the calculation.

(ii) In order for any downtime of the interface to qualify as scheduled downtime, the data provider must have provided reasonable notice of the downtime to all third parties to which the data provider has granted access to the interface. Indicia that the data provider's notice of the downtime may be reasonable include that the notice conforms to a consensus standard.

(iii) The total amount of scheduled downtime for the interface in a calendar month must be reasonable. Indicia that the total amount of scheduled downtime may be reasonable include that the amount conforms to a consensus standard.

(iv) A proper response is a response, other than any message provided during unscheduled downtime of the interface, that meets all of the following criteria:

(A) The response either fulfills the request or explains why the request was not fulfilled;

(B) The response is consistent with the reasonable written policies and procedures that the data provider establishes and maintains pursuant to § 1033.351(a); and

(C) The response is provided by the interface within a commercially reasonable amount of time. Indicia that a response is provided in a commercially reasonable amount of time include conformance to an applicable consensus standard.

(2) Indicia of compliance—(i) Indicia. Indicia that a developer interface's performance is commercially reasonable as required by paragraph (c) of this section include:

(A) Whether the interface's performance conforms to a consensus standard that is applicable to the data provider;

(B) How the interface's performance compares to the performance levels achieved by the developer interfaces of similarly situated data providers; and

(C) How the interface's performance compares to the performance levels achieved by the data provider's consumer interface.

(ii) Performance specifications. For each of the three indicia set forth in paragraph (c)(2)(i) of this section, relevant performance specifications include:

(A) The interface's response rate as defined in paragraphs (c)(1) through (iv) of this section;

(B) The interface's total amount of scheduled downtime;

(C) The amount of time in advance of any scheduled downtime by which notice of the downtime is provided;

(D) The interface's total amount of unscheduled downtime; and

(E) The interface's response time.

(d) Access caps. Except as otherwise permitted by §§ 1033.221, 1033.321, and 1033.331(b) and (c), a data provider must not unreasonably restrict the frequency with which it receives or responds to requests for covered data from an authorized third party through its developer interface. Any frequency restrictions must be applied in a manner that is non-discriminatory and consistent with the reasonable written policies and procedures that the data provider establishes and maintains pursuant to § 1033.351(a). Indicia that any frequency restrictions applied are reasonable include that they conform to a consensus standard.

(e) Security specifications—(1) Access credentials. A data provider must not allow a third party to access the data provider's developer interface by using any credentials that a consumer uses to access the consumer interface. A contract between a data provider and the data provider's service provider, pursuant to which the service provider establishes or maintains the data provider's developer interface, does not violate this paragraph (e)(1) if the contract provides that the service provider will make covered data available, in a form and manner that satisfies the requirements of this part, to authorized third parties through the developer interface by means of the service provider using a consumer's credentials to access the data from the data provider's consumer interface.

(2) Security program. (i) A data provider must apply to the developer interface an information security program that satisfies the applicable rules issued pursuant to section 501 of the Gramm-Leach-Bliley Act, 15 U.S.C. 6801; or

(ii) If the data provider is not subject to section 501 of the Gramm-Leach-Bliley Act, the data provider must apply to its developer interface the information security program required by the Federal Trade Commission's Standards for Safeguarding Customer Information, 16 CFR part 314.

(a) Denials related to risk management. A data provider does not violate the general obligation in § 1033.201(a)(1) by denying a consumer or third party access to all elements of the interface described in § 1033.301(a) if:

(1) Granting access would be inconsistent with policies and procedures reasonably designed to comply with:

(i) Safety and soundness standards of a prudential regulator, as defined at 12 U.S.C. 5481(24), of the data provider;

(ii) Information security standards required by section 501 of the Gramm-Leach-Bliley Act, 15 U.S.C. 6801; or

(iii) Other applicable laws and regulations regarding risk management; and

(2) The denial is reasonable pursuant to paragraph (b) of this section.

(b) Requirements for reasonable denials. A denial is reasonable pursuant to paragraph (a)(2) of this section if it is:

(1) Directly related to a specific risk of which the data provider is aware, such as a failure of a third party to maintain adequate data security; and

(2) Applied in a consistent and non-discriminatory manner.

(c) Indicia bearing on reasonable denials. Indicia bearing on the reasonableness of a denial pursuant to paragraph (b) of this section include:

(1) Whether the denial adheres to a consensus standard related to risk management;

(2) Whether the denial proceeds from standardized risk management criteria that are available to the third party upon request; and

(3) Whether the third party has a certification or other identification of fitness to access covered data that is issued or recognized by a recognized standard setter or the CFPB.

(d) Conditions sufficient to justify a denial. Each of the following is a sufficient basis for denying access to a third party:

(1) The third party does not present any evidence that its information security practices are adequate to safeguard the covered data; or

(2) The third party does not make the following information available in both human-readable and machine-readable formats, and readily identifiable to members of the public, meaning the information must be at least as available as it would be on a public website:

(i) Its legal name and, if applicable, any assumed name it is using while doing business with the consumer;

(ii) A link to its website;

(iii) Its Legal Entity Identifier (LEI) that is issued by:

(A) A utility endorsed by the LEI Regulatory Oversight Committee, or

(B) A utility endorsed or otherwise governed by the Global LEI Foundation (or any successor thereof) after the Global LEI Foundation assumes operational governance of the global LEI system; and

(iv) Contact information a data provider can use to inquire about the third party's information security and compliance practices.

(a) Responding to requests—access by consumers. To comply with the requirements in § 1033.201(a)(1), upon request from a consumer, a data provider must make available covered data when it receives information sufficient to:

(1) Authenticate the consumer's identity; and

(2) Identify the scope of the data requested.

(b) Responding to requests—access by third parties. (1) To comply with the requirements in § 1033.201(a)(1), upon request from an authorized third party, a data provider must make available covered data when it receives information sufficient to:

(i) Authenticate the consumer's identity;

(ii) Authenticate the third party's identity;

(iii) Document the third party has followed the authorization procedures in § 1033.401; and

(iv) Identify the scope of the data requested.

(2) The data provider is permitted to confirm the scope of a third party's authorization to access the consumer's data by asking the consumer to confirm:

(i) The account(s) to which the third party is seeking access; and

(ii) The categories of covered data the third party is requesting to access, as disclosed by the third party pursuant to § 1033.411(b)(4).

Example 1 to paragraph (b): An authorized third party that a data provider has authenticated requests covered data on behalf of an authenticated consumer through the data provider's developer interface. The data provider asks the consumer to confirm the scope of the third party's authorization using a means of communication that the consumer is not accustomed to using with the data provider and that the data provider knows or should know will take a long period of time to reach the consumer and allow the consumer to respond with the confirmation. As a result of the long wait time, the consumer cannot provide a timely confirmation, delaying the third party's access to the covered data. This data provider has violated the § 1033.201(a)(2) prohibition against evasion by taking an action that the data provider knows or should know is likely to interfere with an authorized third party's access to covered data.

(c) Covered data not required to be made available. A data provider is not required to make covered data available in response to a request when:

(1) The data are withheld because an exception described in § 1033.221 applies;

(2) The data are not in the data provider's control or possession, consistent with the requirement in § 1033.201(a)(1).

(3) The data provider's interface is not available when the data provider receives a request requiring a response under this section. However, the data provider is subject to the performance specifications in § 1033.311(c);

(4) The request is for access by a third party; and

(i) The consumer has revoked the third party's authorization pursuant to paragraph (e) of this section;

(ii) The data provider has received notice that the consumer has revoked the third party's authorization pursuant to § 1033.421(h)(2); or

(iii) The consumer has not provided a new authorization to the third party after the maximum duration period, as described in § 1033.421(b)(2).

(5) The data provider has not received information sufficient to satisfy the conditions in paragraph(a) or (b) of this section.

(d) Jointly held accounts. A data provider that receives a request for covered data from a consumer that jointly holds an account or from an authorized third party acting on behalf of such a consumer must make available covered data to that consumer or authorized third party, subject to the other provisions of this section.

(e) Method to revoke third party authorization to access covered data. A data provider does not violate the general obligation in § 1033.201(a)(1) by making available to the consumer a reasonable method to revoke any third party's authorization to access all of the consumer's covered data, provided that such method does not violate § 1033.201(a)(2). Indicia that the data provider's revocation method is reasonable include its conformance to a consensus standard. A data provider that receives a revocation request from a consumer through a revocation method it makes available must revoke the authorized third party's access and notify the authorized third party of the request in a timely manner.

(a) Requirement to make information about the data provider readily identifiable. A data provider must make the information described in paragraphs (b) through (d) of this section:

(1) Readily identifiable to members of the public, meaning the information must be at least as available as it would be on a public website; and

(2) Available in both human-readable and machine-readable formats.

(b) Identifying information. A data provider must disclose in the manner required by paragraph (a) of this section:

(1) Its legal name and, if applicable, any assumed name it is using while doing business with the consumer;

(2) A link to its website;

(3) Its LEI that is issued by:

(i) A utility endorsed by the LEI Regulatory Oversight Committee, or

(ii) A utility endorsed or otherwise governed by the Global LEI Foundation (or any successor thereof) after the Global LEI Foundation assumes operational governance of the global LEI system; and

(4) Contact information that enables a consumer or third party to receive answers to questions about accessing covered data under this part.

(c) Developer interface documentation. For its developer interface, a data provider must disclose in the manner required by paragraph (a) of this section documentation, including metadata describing all covered data and their corresponding data fields, and other documentation sufficient for a third party to access and use the interface. A data provider is not required to make publicly available information that would impede its ability to deny a third party access to its developer interface, consistent with § 1033.321. Indicia that documentation is sufficient for a third party to access and use a developer interface include conformance to a consensus standard. The documentation must:

(1) Be maintained and updated as reasonably necessary for third parties to access and use the interface in accordance with the terms to which data providers are subject under this part;

(2) Include how third parties can get technical support and report issues with the interface; and

(3) Be easy to understand and use, similar to data providers' documentation for other commercially available products.

(d) Performance disclosure. On or before the final day of each calendar month, a data provider must disclose in the manner required by paragraph (a) of this section the quantitative minimum performance specification for the response rate described in § 1033.311(c)(1)(i) through (iv) that the data provider's developer interface achieved in the previous calendar month. The data provider's disclosure must include at least a rolling 13 months of the required monthly figure, except that the disclosure need not include the monthly figure for months prior to the compliance date applicable to the data provider. The data provider must disclose the metric as a percentage rounded to four decimal places, such as “99.9999 percent.”

(a) Reasonable written policies and procedures. A data provider must establish and maintain written policies and procedures that are reasonably designed to achieve the objectives set forth in subparts B and C of this part, including paragraphs (b) through (d) of this section. Policies and procedures must be appropriate to the size, nature, and complexity of the data provider's activities. A data provider has flexibility to design policies and procedures to avoid acting inconsistently with its other legal obligations, or in a way that could reasonably hinder enforcement against unlawful or potentially unlawful conduct. A data provider must periodically review the policies and procedures required by this section and update them as appropriate to ensure their continued effectiveness.

(b) Policies and procedures for making covered data available. The policies and procedures required by paragraph (a) of this section must be reasonably designed to ensure that:

(1) Making available covered data. A data provider creates a record of the data fields of covered data in the data provider's control or possession, what covered data are not made available through a consumer or developer interface pursuant to an exception in § 1033.221, and the reasons the exception applies. Indicia that a data provider's record of such data fields complies with the requirements of this paragraph (b)(1) include listing data fields that conform to those published by a consensus standard.

(2) Denials of developer interface access. When a data provider denies a third party access to a developer interface pursuant to § 1033.321, the data provider:

(i) Creates a record substantiating the basis for denial; and

(ii) Communicates in a timely manner to the third party, electronically or in writing, the reason(s) for the denial.

(3) Denials of information requests. When a data provider denies a request for information for a reason described in § 1033.331(c), to the extent the communication of the denial is not required to be standardized by § 1033.311(b), the data provider:

(i) Creates a record substantiating the basis for the denial; and

(ii) Communicates in a timely manner to the consumer or third party, electronically or in writing, the type(s) of information denied, if applicable, and the reason(s) for the denial.

(c) Policies and procedures for ensuring accuracy—(1) In general. The policies and procedures required by paragraph (a) of this section must be reasonably designed to ensure that covered data are accurately made available through the data provider's developer interface.

(2) Elements. In developing its policies and procedures regarding accuracy, a data provider must consider, for example:

(i) Implementing the format requirements of § 1033.311(b); and

(ii) Addressing information provided by a consumer or a third party regarding inaccuracies in the covered data made available through its developer interface.

(3) Indicia of compliance. Indicia that a data provider's policies and procedures regarding accuracy are reasonable include whether the policies and procedures conform to a consensus standard regarding accuracy.

(d) Policies and procedures for record retention. The policies and procedures required by paragraph (a) of this section must be reasonably designed to ensure retention of records that are evidence of compliance with subparts B and C of this part.

(1) Retention period. Records that are evidence of a data provider's actions in response to a consumer's or third party's request for information or a third party's request to access a developer interface must be retained for at least three years after a data provider has responded to the request. All other records that are evidence of compliance with subparts B and C of this part must be retained for a reasonable period of time of at least three years from the date of the action required under subparts B and C of this part.

(2) Certain records retained pursuant to policies and procedures. Records retained pursuant to policies and procedures required under paragraph (a) of this section must include, without limitation:

(i) Records documenting requests for a third party's access to an interface, actions taken in response to such requests, and reasons for denying access, if applicable, for at least three years after the data provider has responded to the request;

(ii) Records providing evidence of fulfillment of requests for information, actions taken in response to such requests, and reasons for not making the information available, if applicable, for at least three years after the data provider has responded to the request;

(iii) Records documenting that the third party has followed the authorization procedures in § 1033.401 to access data on behalf of a consumer, for at least three years after such records are generated;

(iv) Records providing evidence of actions taken by a consumer and a data provider to revoke a third party's access pursuant to any revocation method made available by a data provider, for at least three years after the revocation;

(v) Records providing evidence of commercially reasonable performance described in § 1033.311(c)(2)(ii), for at least three years after the period recorded;

(vi) Written policies and procedures required under this section for three years from the time such material was last applicable; and

(vii) Disclosures required under § 1033.341, for three years from the time such material was disclosed to the public.