Tech & Sourcing @ Morgan Lewis

The Clearing House (the oldest banking association and payments company in the United States) recently released a model agreement as a voluntary starting point to facilitate data sharing between financial institutions and fintech companies.

The model agreement is intended to provide a standardized foundation that speeds up data access agreement negotiations; as the Clearing House notes, “[L]egal agreements between banks and fintechs have sometimes taken 12 months or more to be developed and finalized and have become a significant bottleneck to API adoption.” Additionally, the model agreement is designed to reflect the Consumer Financial Protection Bureau’s consumer protection principles on data sharing and aggregation, providing confidence to the contracting parties that the terms address key regulatory issues.

However, as with any model agreement, (i) specific circumstances will dictate whether certain terms should be amended, replaced, or supplemented or whether one party has greater negotiating power; (ii) some participants, having strong preferences (regarding substance and/or form) and established procedures, will resist change; and (iii) this is a living document that will adapt, like the burgeoning industry for which it was crafted, to user behavior and the evolving regulatory terrain.

Specific provisions and concepts in the model agreement worth noting include the following:

• Flow-Down Obligations. These types of obligations, if rigid or overly specific, can be burdensome and, in many cases, impractical. Some hosting and other service providers have standard, non-negotiable terms relating to security, audits, liability, and other relevant matters. Under the model agreement, the data recipient has several obligations that also apply to third parties. For example:
  • Under Section 4.10, the data recipient (i.e., fintech company) must enter into substantially similar agreements with any of its developers/integrators that receive data provider (i.e., financial institution) customer account information via the data feed.
  • Under Section 8.6, the data recipient must provide a list of its relevant subcontractors and integrators. In the requirements and defined terms of the model agreement, these third parties are deeply embedded. For example, the data provider has the right to audit and inspect the records and systems of any such entity, including conducting onsite reviews, assessments, and testing.
  • Under Section 9.2(d), the data recipient warrants that “Data Recipient Access Systems” do not infringe any third-party proprietary rights. Under the model agreement, Data Recipient Access Systems include relevant systems used by subcontractors. Thus, the data recipient would want to receive a similar warranty from its subcontractors.
  • Under Section 13.6, the data recipient must notify the data provider of any changes that may impact security. Therefore, to ensure that the data recipient has the knowledge and rights necessary to comply with this requirement, the data recipient would need to impose a similar obligation on its service providers.
  • Section 13.7 lists several data security requirements and incorporates an exhibit with additional safeguards. Under the terms of the model agreement, the data recipient’s service providers must implement these safeguards and must comply with security requirement changes made by the data provider unilaterally.
  • Under Section 14.4(c), the data recipient must reimburse the data provider for reasonable, customary, out-of-pocket expenses attributable to the data recipient’s breach of its confidentiality or data protection obligations. Note that:
    • The non-exhaustive list of reimbursable expenses is extensive, including costs associated with public relations and crisis management. However, the data provider should consider whether this provision, as currently drafted, fails to adequately cover significant potential damages. Qualifiers like “customary” and “out-of-pocket” would limit the data provider’s recovery, and this provision appears to be limited to a breach by the data recipient of its express obligations (which might exclude security breaches that occur despite the data recipient’s compliance with the applicable security requirements, an issue we previously discussed). Similarly, under Section 14.4(b), “breach of confidentiality under Article 13” is an exception to the limitation on consequential damages; it is unclear whether a Security Breach, despite the data recipient’s implementation of the required safeguards, would fall within the scope of this exception.
    • The data recipient should be mindful of Section 15.11, which states that all remedies are cumulative and non-exclusive. The data recipient should, therefore, consider (i) amending Section 15.11 to allow for specifically stated exceptions to that general rule; and (ii) expressly stating in Section 14.4(c) that the listed remedies are the data provider’s exclusive remedies for any such breach.
• Data Breach
  • The definition of “Security Breach” is relatively broad and includes any “reasonably suspected” unauthorized disclosure or cyber risk (i.e., system vulnerability). This definition is important in several ways, including (i) the data provider’s right to terminate/suspend; (ii) the data recipient’s notification, cooperation, investigation, and remediation obligations; and (iii) potentially (as further discussed below), the data recipient’s liability.
  • One item of particular note for the data provider is that, under Section 13.8(b)(ii), the data recipient must notify affected individuals. The data provider should assess whether it wants the right to approve or control any such notification activities.
• Liability
  • The data recipient’s indemnification obligations in Section 14.1 are wider in scope than those of the data provider in Section 14.2, even after taking into account the different roles of the respective parties. For example:
    • The data recipient indemnifies for its breach of the agreement, whereas the data provider does not have the reciprocal obligation. The data recipient should consider (i) imposing additional compliance obligations on the data provider; and (ii) adding the data provider’s breach of the agreement to the list in Section 14.2.
    • The data provider’s infringement indemnification obligation is specifically limited to the data distribution channel it provides, whereas the data recipient’s infringement indemnification obligation includes any materials or other resources that the data recipient uses or provides. The data recipient should consider broadening the scope of the data provider’s infringement indemnity to include any materials that the data provider provides to the data recipient (e.g., software or documentation useful for integration but not included within the scope of the “Data Access Method”).
• Warranties and Disclaimers
  • Under Section 4.9, the data provider essentially disclaims all warranties relating to its data distribution channel. The data recipient should assess whether it is relying on any accuracy, availability or other aspects of the data distribution channel.
  • Under Section 9.2(c), the data recipient must meet generally accepted standards applicable to “nationally recognized firms specializing in data access.” Early-stage fintech companies should evaluate whether their systems, procedures and standards are on par with nationally recognized players. Similarly, fintech companies with limited resources should consider whether they can comply with background check requirements and all applicable data provider policies.
  • Under Section 9.2(e), the data recipient must prevent the introduction or proliferation of any computer virus. Given that it’s nearly impossible to prevent viruses with 100% success, the data recipient should consider refocusing this warranty on the safeguards (i.e., antivirus software) it will employ.
• Intellectual Property
  • Under the model agreement, the data provider owns the data distribution channel and related materials and information. The data recipient should evaluate the level of its involvement in developing and integrating the data distribution channel and, accordingly, (i) amend the intellectual property-related definitions and terms to protect the data recipient’s proprietary rights; and/or (ii) make operational adjustments to avoid creating valuable materials that will be owned by the data provider.
  • Although obligations to return or destroy proprietary information are common and understandable, each party should assess whether it will need the right to retain certain data in accordance with routine backup procedures.
• Disclosure and Consent. The data recipient should ensure that it can comply with all of the customer disclosure and consent requirements set forth in Article 5.
• Termination and Suspension. The data recipient should note that the data provider has broad, unilateral termination and suspension rights under Article 11. The data recipient should consider, at minimum, making the termination for cause provision mutual.
• Assignment. Under Section 15.4, each party needs the other party’s prior written consent to any assignment (including any change of control). Early-stage companies, in particular, should consider whether they have sufficient corporate flexibility for their potential exit strategies. Complex financial institutions, in particular, should evaluate whether they have sufficient corporate flexibility for reorganizations or other inter-affiliate transfers.