(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.