MEMORANDUM

MEMORANDUM
PRIVILEGED AND CONFIDENTIAL ATTORNEY-CLIENT COMMUNICATION / ATTORNEY WORK PRODUCT
TO: Kevin Ostrowski, Responsible Partner, Privacy & Data Security, Calderwood & Harkness LLP Thomas Elridge, General Counsel / Chief Privacy Officer, Skybridge Fintech Ltd.
FROM: Priscilla Wynn, Lead Associate, Privacy & Data Security Alan Burke, Working Associate, Privacy & Data Security
DATE: December 5, 2025
RE: Gap Analysis — Meridian Federal Savings Bank Form DPA vs. Skybridge Fintech Ltd. Existing Template and Market Standards
MATTER NO.: 1009-00004
This memorandum is a privileged and confidential attorney-client communication and attorney work product. It is prepared at the direction of counsel for the purpose of providing legal advice and is protected from disclosure by the attorney-client privilege, the work product doctrine, and all other applicable privileges and protections. This memorandum and its contents should not be disclosed to any third party without the prior written consent of Calderwood & Harkness LLP. Any inadvertent disclosure does not constitute a waiver of any applicable privilege or protection.
Right-click to update Table of Contents
I. Executive Summary
The purpose of this memorandum is to analyze the key differences between Meridian Federal Savings Bank's ("Meridian" or "MFSB") form Data Processing Agreement (the "Meridian Form DPA"), received from Meridian's outside counsel, Blackwell, Raines & Stoddard LLP ("BRS"), on November 25, 2025, and Skybridge Fintech Ltd.'s ("Skybridge" or "SBF") existing customer-facing DPA template (the "Skybridge Template"). This memorandum is intended to inform the development of a Skybridge counter-proposal DPA that satisfies Meridian's institutional and regulatory requirements, while establishing Skybridge's standardized "bank-grade" template for all future similarly situated bank clients.
Meridian is a federally chartered savings bank operating under OCC Charter No. 14-2238 and insured by the Federal Deposit Insurance Corporation. Meridian is headquartered at 900 Broad Street, Suite 1200, Newark, New Jersey 07102, and maintains approximately $6.1 billion in total assets. Meridian serves approximately 412,000 accountholders, including approximately 3,200 accountholders who are residents of the European Union. As a federally chartered savings bank, Meridian is subject to supervision and examination by the Office of the Comptroller of the Currency ("OCC"), the Federal Deposit Insurance Corporation ("FDIC"), and, for consumer protection purposes, the Consumer Financial Protection Bureau ("CFPB").
Meridian is currently undertaking a significant technology migration, transitioning from its legacy in-house payment processing and fraud detection system to Skybridge's SBF Core platform under a five-year Software-as-a-Service subscription agreement. The commercial terms of that subscription agreement provide for an annual contract value ("ACV") of approximately $2.74 million per year, resulting in a total contract value ("TCV") of approximately $13.7 million over the five-year term. SBF Core will serve as Meridian's primary platform for payment processing, anti-fraud analytics, and certain regulatory reporting functions. Given the nature and scope of the personal data that will flow through SBF Core in connection with these services, a negotiated data processing agreement is both a regulatory imperative and a commercial prerequisite to execution of the underlying subscription agreement.
Meridian's Third-Party Risk Management ("TPRM") program, which is aligned with OCC Bulletin 2023-17 (Third-Party Risk Management) and guidance issued by the Federal Financial Institutions Examination Council ("FFIEC"), requires that a fully negotiated DPA — together with a Standard Contractual Clauses package addressing international data transfers — be executed and finalized before the SaaS subscription agreement can be signed. Meridian's TPRM program classifies SBF Core as a "critical activity" vendor relationship, which subjects it to heightened due diligence, ongoing monitoring, and specific contractual requirements. The current target date for execution of both the DPA and the subscription agreement is February 15, 2026.
This memorandum identifies nine key areas of divergence between the Meridian Form DPA and the Skybridge Template, and provides recommended positions for the Skybridge counter-proposal with respect to each area. Our recommendations are benchmarked against prevailing market standards for bank-vendor data processing agreements, drawing on our experience advising on comparable transactions and our review of publicly available and proprietary precedent agreements in the financial services sector.
In addition to satisfying Meridian's specific requirements, the goal of this engagement is to produce a counter-proposal DPA that can serve as Skybridge's standardized bank-grade template for deployment across all future bank client relationships. Accordingly, our recommendations are designed to be scalable, employing formula-based provisions and modular structures that can accommodate clients with varying ACVs, regulatory profiles, and data processing scopes.
We note for the record that the Meridian Form DPA was drafted by Constance Liu, Partner in the Financial Services and Data Privacy practice group at BRS, and Derek Faulkner, Associate, also of BRS. Ms. Liu is a well-regarded practitioner in the financial services data privacy space and has previously been involved in several high-profile bank-vendor DPA negotiations. We anticipate that BRS will be a sophisticated counterparty in negotiations, and our counter-proposal should be carefully calibrated to reflect positions that are defensible, well-reasoned, and grounded in market practice.
II. Background and Scope
A. Parties and Roles
For purposes of this memorandum and the data processing relationship at issue, the parties and their respective roles under applicable data protection law are as follows:
Meridian Federal Savings Bank acts as the Data Controller. Meridian is the entity that determines the purposes and means of the processing of personal data in connection with the services to be provided by Skybridge under the SaaS subscription agreement. Meridian is a federally chartered savings bank subject to supervision by the OCC, the FDIC, and the CFPB. Meridian's principal place of business is 900 Broad Street, Suite 1200, Newark, New Jersey 07102.
Skybridge Fintech Ltd. acts as the Data Processor. Skybridge is a Delaware C-corporation that provides the SBF Core platform — a SaaS solution encompassing payment processing, anti-fraud analytics, and regulatory reporting capabilities. Skybridge processes personal data on behalf of Meridian, and only in accordance with Meridian's documented instructions, in the course of delivering the SBF Core services. Skybridge's principal office is located at 2200 Market Street, Suite 1800, Philadelphia, Pennsylvania 19103.
The following entities are key sub-processors in the processing chain:
(i) Osprey Cloud Infrastructure, Inc. ("Osprey Cloud" or "OCI") — Osprey Cloud serves as Skybridge's primary infrastructure-as-a-service ("IaaS") and platform-as-a-service ("PaaS") provider. Osprey Cloud hosts the SBF Core platform and stores personal data processed on behalf of Meridian at two principal data center locations: (a) the US-East data center located in Ashburn, Virginia (primary production environment and disaster recovery via a secondary availability zone at the same facility); and (b) the EU data center located in Frankfurt, Germany (dedicated to EU-resident personal data). The existing Skybridge–Osprey Cloud DPA, dated March 1, 2024, includes Module 3 Standard Contractual Clauses governing processor-to-sub-processor transfers.
(ii) Skybridge Fintech Europe B.V. ("SBF Europe") — SBF Europe is Skybridge's EU-based subsidiary, incorporated in the Netherlands (KvK Registration No. 82104593) and headquartered in Amsterdam. SBF Europe functions as a sub-processor for personal data of EU-resident data subjects, providing local EU data processing and serving as Skybridge's EU establishment for purposes of the General Data Protection Regulation.
We also note for context that Halcyon Ridge Capital Partners, LP holds approximately 34.2% of Skybridge's equity in the form of Series B preferred stock. While Halcyon Ridge does not directly participate in data processing activities, its position as a significant equity holder may be relevant in the context of Meridian's TPRM due diligence and corporate governance review. Meridian's TPRM questionnaire includes several questions regarding ownership structure and control, which have been addressed separately in Skybridge's questionnaire responses.
B. Data Processing Scope
The scope of personal data processing under the contemplated SBF Core engagement encompasses the following categories:
Categories of Data Subjects. The personal data processed through SBF Core relates to the following categories of data subjects: (i) Meridian accountholders, including both retail (individual) and small-business accountholders; (ii) authorized signers on Meridian accounts; (iii) beneficial owners of accounts, as disclosed in connection with Customer Identification Program ("CIP") and Customer Due Diligence ("CDD") requirements; and (iv) Meridian employees whose personal data passes through the SBF Core platform in connection with internal payment processing or administrative functions.
Categories of Personal Data. The categories of personal data that will be processed through SBF Core include, but are not limited to: full legal name; date of birth; Social Security Number ("SSN"); Taxpayer Identification Number ("TIN"); account numbers (checking, savings, and loan accounts); routing numbers; transaction amounts and associated metadata (including timestamps, merchant category codes, and transaction descriptions); Internet Protocol ("IP") addresses; device identifiers; geolocation data (city-level granularity); email addresses; telephone numbers; and anti-fraud behavioral biometric data, specifically including keystroke dynamics and mouse movement patterns captured by SBF Core's behavioral analytics module.
Sensitive Personal Data. Certain categories of the personal data described above qualify as "sensitive" under applicable data protection laws. In particular: (i) Social Security Numbers are considered sensitive personal information under the California Consumer Privacy Act, as amended by the California Privacy Rights Act ("CCPA/CPRA"), and under the expected New Jersey Data Privacy Act (S3377); and (ii) behavioral biometric data (keystroke dynamics and mouse movement patterns) is classified as sensitive personal information under CCPA/CPRA and is expected to be similarly categorized under New Jersey S3377. The processing of these sensitive data categories will require heightened security measures and specific contractual protections, which we address in Section V.B below.
Data Volume. The SBF Core platform will process personal data relating to approximately 412,000 data subjects. Meridian processes approximately 18.6 million transactions per month through its existing payment infrastructure, and this volume is expected to migrate to SBF Core upon completion of the technology transition.
EU Data Subjects. Approximately 3,200 Meridian accountholders are residents of the European Union. The personal data of these EU-resident data subjects triggers the applicability of the General Data Protection Regulation ("GDPR") and necessitates the implementation of appropriate international data transfer mechanisms, including Standard Contractual Clauses pursuant to EU Commission Implementing Decision 2021/914. This EU data subject population, while constituting less than one percent of Meridian's total accountholder base, introduces significant compliance complexity and is a primary driver of the SCC requirements discussed in Section III.H below.
Data Locations. Personal data processed under the SBF Core engagement will be stored and processed at the following locations: (i) Osprey Cloud US-East (Ashburn, Virginia) — primary production environment for all personal data; (ii) Osprey Cloud EU (Frankfurt, Germany) — dedicated environment for EU-resident personal data; (iii) SBF Europe (Amsterdam, Netherlands) — EU data processing operations; and (iv) Osprey Cloud US-East secondary availability zone (Ashburn, Virginia) — disaster recovery environment. The geographic distribution of data processing operations is relevant to both the international transfer analysis and the audit rights provisions discussed in this memorandum.
C. Applicable Regulatory Framework
The data processing relationship between Meridian and Skybridge is subject to a complex, multi-layered regulatory framework spanning federal banking law, US state privacy law, and European data protection law. The principal regulatory authorities and legal instruments applicable to the contemplated arrangement include:
•  Gramm-Leach-Bliley Act ("GLBA") and Regulation P (12 CFR Part 1016): Govern the collection, use, and disclosure of nonpublic personal information by financial institutions and impose obligations on service providers that receive such information.
•  OCC Bulletin 2023-17 (Third-Party Risk Management): Provides comprehensive guidance to national banks and federal savings associations regarding the management of risks arising from third-party relationships, with particular emphasis on "critical activities" and the contractual provisions that should govern such relationships.
•  FDIC/OCC Computer-Security Incident Notification Rule (12 CFR Part 53): Requires banking organizations to notify their primary federal regulator no later than 36 hours after determining that a "notification incident" has occurred, and requires bank service providers to notify the bank "as soon as possible" after determining that a computer-security incident has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, covered services provided to the bank.
•  General Data Protection Regulation ("GDPR") (Regulation (EU) 2016/679): Applicable to the processing of personal data of the approximately 3,200 EU-resident Meridian accountholders, including obligations regarding processor agreements (Article 28), breach notification (Article 33), and international data transfers (Chapter V).
•  California Consumer Privacy Act / California Privacy Rights Act ("CCPA/CPRA"): Applicable to personal information of California-resident Meridian accountholders and imposing requirements on service providers, including specific contractual provisions.
•  New Jersey Data Privacy Act (S3377): Expected to become effective on January 15, 2026. Given Meridian's New Jersey headquarters and significant New Jersey accountholder population, this statute will impose additional obligations regarding the processing of personal data, including provisions addressing sensitive data and processor agreements.
•  *Schrems II* (Case C-311/18, *Data Protection Commissioner v. Kestrel Services Inc. Ireland Limited and Maximillian Schrems*): The Court of Justice of the European Union's 2020 decision invalidating the EU-US Privacy Shield and imposing supplementary measures requirements for Standard Contractual Clauses-based transfers, which directly impacts the transfer mechanisms required for EU-resident accountholder data.
A separate, comprehensive Regulatory Landscape Overview memorandum is being prepared concurrently by this team and will provide a detailed analysis of each applicable regulatory instrument and its specific implications for the DPA and SCC package. That memorandum is targeted for completion by December 3, 2025, and may already be in final review as of the date of this memorandum.
D. Documents Reviewed
In preparing this gap analysis, we have reviewed the following documents:
1.  Meridian Form DPA, as received from Blackwell, Raines & Stoddard LLP on November 25, 2025 (52 pages, including schedules and exhibits).
2.  Skybridge Fintech Ltd. existing customer-facing DPA template (current internal version, last revised August 2025, 28 pages).
3.  Meridian Federal Savings Bank Third-Party Risk Management Due Diligence Questionnaire, received from BRS on November 25, 2025 (146 questions across 8 sections).
4.  Existing Skybridge Fintech Ltd.–Osprey Cloud Infrastructure, Inc. Data Processing Agreement, dated March 1, 2024, including Module 3 Standard Contractual Clauses (Processor-to-Sub-processor) (38 pages).
5.  SOC 2 Type II Report for Skybridge Fintech Ltd. SBF Core Platform, issued by Graystone & Ketchum LLP, dated September 15, 2025 (audit period: October 1, 2024 – September 15, 2025) (Trust Services Criteria: Security, Availability, Processing Integrity, Confidentiality).
6.  Bastion Mutual Insurance Company Cyber-Liability Insurance Policy, Policy No. CYB-2025-04821 ($10 million per occurrence / $20 million aggregate; policy period: January 1, 2025 – December 31, 2025), issued through Kestrel Risk Advisors LLC (broker).
III. Gap Analysis — Key Areas of Divergence
This section sets forth our detailed analysis of the nine key areas of divergence between the Meridian Form DPA and the Skybridge Template. For each area, we describe the positions taken by each party's respective document, identify the prevailing market standard for bank-vendor data processing agreements of comparable scope and size, and provide our recommended position for the Skybridge counter-proposal.
A. Liability Cap
1. Meridian Form DPA Position
The Meridian Form DPA proposes an approach to liability that is notably aggressive from the Controller's perspective. Section 12.1 of the Meridian Form DPA provides that the Processor's liability for breaches of the DPA shall be uncapped — that is, the Processor would bear unlimited aggregate liability for any and all losses, damages, claims, and expenses arising from or related to any breach of the DPA by the Processor. In the alternative, Section 12.1 includes a bracketed option indicating that Meridian may be willing to accept a very high fixed-dollar cap equal to three times the Total Contract Value (3× TCV), which in the context of the Skybridge engagement would equal approximately $41.1 million (3 × $13.7 million TCV).
In addition, the Meridian Form DPA carves out certain categories of breach from any liability cap, designating them as "super cap" or "unlimited liability" events. These include: (a) data breaches affecting Meridian accountholder personal data; (b) willful misconduct or gross negligence by the Processor or its personnel; and (c) breach of the confidentiality obligations set forth in the DPA. In effect, even if a fixed-dollar cap were agreed upon, the most significant categories of potential liability would remain uncapped under the Meridian Form DPA's framework.
2. Skybridge Template Position
The Skybridge Template takes a significantly more conservative approach to liability. Section 9.1 of the Skybridge Template provides that the Processor's aggregate liability under the DPA shall be capped at an amount equal to one times (1×) the fees paid by the Controller in the twelve-month period immediately preceding the event giving rise to the claim (i.e., the trailing-12-month fee amount). For the Meridian engagement, this would result in a cap of approximately $2.74 million.
Critically, the Skybridge Template does not include any carve-outs from this cap. Under the current Skybridge Template, all categories of liability — including liability arising from data breaches, willful misconduct, and breaches of confidentiality — would be subject to the same aggregate cap. While this approach provides Skybridge with maximum predictability of liability exposure, it is unlikely to be acceptable to a regulated financial institution client whose TPRM program requires adequate contractual protections for its accountholder data.
3. Market Standard
Our review of precedent bank-vendor DPAs and our experience advising on comparable transactions indicate that the market standard for liability caps in mid-market bank-vendor data processing agreements typically employs a formula-based approach. The most common structure is to set the liability cap at the greater of: (a) a fixed-dollar floor (commonly ranging from $3 million to $10 million, depending on the size and criticality of the engagement) or (b) a multiple of trailing-12-month fees (commonly ranging from 1× to 3× such fees).
This formula-based approach balances the Controller's need for meaningful contractual protection against the Processor's interest in maintaining a liability exposure that is proportionate to the revenue derived from the engagement. The fixed-dollar floor ensures that Controllers receiving smaller fee amounts are not left with an inadequately small cap, while the fee-based multiplier ensures that the cap scales appropriately for larger engagements.
Super-cap carve-outs for willful misconduct, fraud, or intellectual property infringement are relatively common in market practice, with such carved-out liabilities subject to a higher cap (e.g., 2× or 3× the base cap) or, less frequently, treated as uncapped. However, unlimited liability across all breach categories is disfavored by processors and is not the prevailing market standard, even in agreements with large financial institution clients. For a deal with an ACV of approximately $2.74 million per year, a cap in the range of $5 million to $8 million is typical.
4. Recommendation.  We recommend that the Skybridge counter-proposal include a liability cap structured as follows:
The Processor's aggregate liability under this Data Processing Agreement shall not exceed the greater of (a) Five Million United States Dollars ($5,000,000) or (b) two times (2×) the aggregate fees paid by the Controller to the Processor in the twelve (12) month period immediately preceding the event giving rise to the claim.
For the Meridian engagement specifically, this formula yields a cap of 2 × $2.74 million = $5.48 million, which exceeds the $5.0 million fixed-dollar floor. The operative cap for Meridian would therefore be $5.48 million. This is a defensible, market-standard position that provides Meridian with meaningful protection while keeping Skybridge's exposure proportionate to the revenue derived from the engagement.
The formula-based approach is also particularly well-suited to a template agreement intended for deployment across multiple bank clients. For clients with lower ACVs, the $5.0 million floor ensures adequate protection; for clients with higher ACVs, the 2× multiplier scales the cap proportionately. This structure should be acceptable to a range of bank counterparties without requiring bespoke renegotiation of the liability cap for each engagement.
As a negotiation strategy, we note that willful misconduct and fraud could potentially be carved out from the cap and made subject to either a higher "super cap" (e.g., 2× the base cap) or unlimited liability, if necessary as a concession during negotiations with BRS. However, Skybridge should resist unlimited liability as a starting position, and any super-cap carve-outs should be narrowly defined and limited to intentional misconduct or fraud — not extended to ordinary data breaches, which should remain subject to the base cap. We anticipate that Ms. Liu at BRS will push for broader carve-outs, and Skybridge should be prepared to negotiate this point but should not concede unlimited liability for data breach claims.
B. Indemnification
1. Meridian Form DPA Position
Section 13 of the Meridian Form DPA imposes a broad, one-directional indemnification obligation on the Processor. Under the Meridian Form DPA, Skybridge would be required to indemnify, defend, and hold harmless Meridian and its officers, directors, employees, agents, and affiliates from and against all losses, liabilities, damages, costs, and expenses (including reasonable attorneys' fees and costs of investigation) arising from or related to any breach of the DPA by the Processor or any of the Processor's sub-processors.
The Meridian Form DPA indemnification provision is notable in several respects. First, it expressly includes indemnification for regulatory fines and penalties imposed on the Controller (Meridian) by any regulatory authority, including but not limited to the OCC, FDIC, CFPB, or any state regulatory authority, to the extent such fines or penalties arise from or relate to the Processor's acts, omissions, or breaches of the DPA. Second, the indemnification obligation is not subject to any cap — it operates independently of the liability limitation provision, meaning the Processor's indemnification exposure could exceed the stated liability cap. Third, the indemnification obligation is one-directional only: the Processor indemnifies the Controller, but the Controller has no reciprocal obligation to indemnify the Processor for any claims arising from the Controller's breach of the DPA. Mutual indemnification is not contemplated.
2. Skybridge Template Position
The Skybridge Template does not include an indemnification provision in the DPA itself. The Skybridge Template relies instead on the limitation of liability clause contained within the DPA and defers indemnification matters to the underlying SaaS subscription agreement. Skybridge's standard SaaS subscription agreement includes mutual indemnification provisions covering intellectual property infringement and data breaches, but the DPA — as a standalone document appended to the subscription agreement — is silent on indemnification.
This approach, while internally consistent from Skybridge's perspective, creates a gap that is likely to be identified by any regulated financial institution conducting TPRM due diligence. The absence of an express indemnification provision in the DPA may be viewed by Meridian (and by its regulators during examination) as a deficiency in the contractual framework governing the third-party data processing relationship.
3. Market Standard
The inclusion of an express indemnification provision in the DPA is increasingly common in bank-vendor data processing agreements, particularly in the wake of OCC Bulletin 2023-17, which emphasizes the importance of contractual provisions that allocate risk appropriately in third-party relationships involving critical activities. Bank examiners reviewing the TPRM file for a critical-activity vendor relationship will expect to see indemnification provisions that provide the bank with recourse in the event of a Processor breach.
In market-standard bank-vendor DPAs, the indemnification obligation typically covers third-party claims (including claims brought by data subjects and regulatory enforcement actions) arising from the Processor's breach of the DPA. Indemnification for regulatory fines is permissible to the extent not prohibited by applicable law. We note that certain jurisdictions limit or prohibit contractual indemnification for certain categories of regulatory fines — for example, fines imposed for a party's own willful misconduct may not be indemnifiable in some jurisdictions. Notwithstanding these limitations, inclusion of regulatory fine indemnification (to the extent permissible under applicable law) is standard market practice.
Importantly, in prevailing market practice, the indemnification obligation is subject to the DPA's overall liability cap. Indemnification that operates independently of the cap (i.e., uncapped indemnification) is not the market norm for processor agreements and is generally resisted by processors.
One-directional indemnification (Processor indemnifies Controller) is the standard approach in Controller-Processor DPAs. Mutual indemnification is less common in this context because the Controller is typically the party bearing the primary regulatory exposure and the Processor is the party performing the data processing activities that give rise to the relevant risks. This one-directional structure is consistent with the allocation of roles and responsibilities under GDPR Article 28 and analogous US frameworks.
4. Recommendation.  We recommend that Skybridge accept the inclusion of an express indemnification provision in the DPA. This is necessary to satisfy Meridian's TPRM program requirements and will be expected by future bank clients for whom this DPA will serve as a template. The absence of an indemnification provision in Skybridge's current template is a notable gap that should be addressed in the counter-proposal.
The indemnification provision should be structured as follows:
•  Scope: Skybridge shall indemnify, defend, and hold harmless the Controller from and against third-party claims (including claims by data subjects and regulatory enforcement actions) arising from Skybridge's breach of the DPA, including regulatory fines and penalties to the extent such indemnification is permissible under applicable law.
•  Cap: The indemnification obligation shall be subject to the overall liability cap (i.e., the greater of $5.0 million or 2× trailing-12-month fees). Skybridge should resist any attempt by BRS to carve indemnification out from the cap or to impose uncapped indemnification.
•  Procedures: The indemnification provision should include standard indemnification procedures, including: (a) the indemnified party must provide prompt written notice of any claim; (b) the indemnified party must reasonably cooperate in the defense of the claim; and (c) the indemnifying party shall have the right to assume sole control of the defense and settlement of the claim (provided that no settlement that imposes obligations on the indemnified party beyond the payment of money shall be entered into without the indemnified party's consent).
The one-directional structure (Processor indemnifies Controller) is appropriate and need not be resisted; this is consistent with market practice and with the allocation of data protection roles in the Meridian-Skybridge relationship. Skybridge should, however, ensure that the indemnification language clearly conditions the Processor's obligation on the Controller's compliance with its own obligations under the DPA — that is, the Processor should not be required to indemnify the Controller for losses arising from the Controller's own breach or failure to comply with the DPA.
C. Breach Notification Timeline
1. Meridian Form DPA Position
Section 7.1 of the Meridian Form DPA requires the Processor to notify the Controller of a Personal Data Breach within twenty-four (24) hours of the Processor becoming aware of such breach. The Meridian Form DPA defines "awareness" broadly, including constructive awareness (i.e., when the Processor should reasonably have become aware of the breach based on the exercise of reasonable diligence).
Section 7.2 of the Meridian Form DPA sets forth detailed initial notification content requirements. The Processor's notification to the Controller must include, at a minimum: (a) a description of the nature of the Personal Data Breach, including, where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned; (b) the name and contact details of the Processor's data protection officer or other contact point where more information can be obtained; (c) a description of the likely consequences of the Personal Data Breach; and (d) a description of the measures taken or proposed to be taken by the Processor to address the Personal Data Breach, including, where appropriate, measures to mitigate its possible adverse effects. These content requirements substantially mirror those set forth in GDPR Article 33(3), but with additional specificity regarding the estimated number of data subjects and the categories of data affected.
2. Skybridge Template Position
Section 6.1 of the Skybridge Template provides for a seventy-two (72) hour notification timeline from the point at which the Processor becomes aware of a Personal Data Breach. The Skybridge Template defines awareness more narrowly than the Meridian Form DPA, referencing actual (rather than constructive) awareness by the Processor's designated incident response team.
The notification content requirements in the Skybridge Template are more abbreviated than those in the Meridian Form DPA. The Skybridge Template requires the notification to include a general description of the nature of the breach and the measures being taken in response, in language that aligns with GDPR Article 33(3) but omits the more granular detail required by Meridian's form.
3. Market Standard
The applicable regulatory framework provides important context for evaluating breach notification timelines in bank-vendor DPAs. The FDIC/OCC Computer-Security Incident Notification Rule (12 CFR Part 53) requires banking organizations to notify their primary federal regulator no later than 36 hours after the banking organization determines that a "notification incident" has occurred. Separately, bank service providers (a category that would include Skybridge) are required to notify the affected banking organization "as soon as possible" after the service provider determines that a computer-security incident has occurred that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, the covered services provided to the banking organization.
In practice, bank-vendor DPAs typically specify a Processor-to-Controller notification period of 48 or 72 hours. A 24-hour notification timeline is aggressive and operationally difficult for processors, as it leaves insufficient time for the processor's incident response team to assess the nature and scope of the incident, confirm that a notifiable breach has in fact occurred (as opposed to a false positive or a security event that does not constitute a personal data breach), and assemble the detailed information required by the notification content provisions. The emerging market standard for critical bank-vendor relationships is 48 hours, which balances the Controller's legitimate need for timely information with the Processor's operational need for adequate time to investigate and assess the incident.
We note that Meridian's own TPRM program materials, as reflected in the TPRM due diligence questionnaire received on November 25, 2025, indicate that Meridian's internal TPRM policy requires vendor notification of security incidents within 48 hours or less. This suggests that a 48-hour notification timeline would satisfy Meridian's internal requirements, notwithstanding the more aggressive 24-hour timeline reflected in the BRS-drafted form DPA.
4. Recommendation.  We recommend that the Skybridge counter-proposal include a 48-hour notification timeline, revised from Skybridge's current 72-hour template standard. This adjustment brings Skybridge's position into alignment with Meridian's TPRM program requirements, prevailing market practice, and the regulatory expectations established by the FDIC/OCC Computer-Security Incident Notification Rule. We believe this position is defensible and should be accepted by BRS during negotiations, particularly given that it is consistent with Meridian's own internal TPRM policy.
Skybridge should resist the 24-hour notification timeline proposed in the Meridian Form DPA as operationally impractical. A 24-hour window provides insufficient time for Skybridge's incident response team — led by Chief Information Security Officer Rebecca Muñoz — to conduct the preliminary investigation necessary to provide a meaningful and accurate notification. A premature or inaccurate notification may itself create risks for both parties, including the risk of triggering unnecessary regulatory notifications and public disclosures based on incomplete or erroneous information.
With respect to notification content, we recommend that Skybridge accept the detailed notification content requirements proposed in the Meridian Form DPA, with minor modifications to permit a phased notification approach. Specifically, the DPA should provide that the Processor may deliver an initial notice containing the information available at the time of notification (which may be preliminary and incomplete), followed by supplemental notices as additional information becomes available through the Processor's ongoing investigation. This phased approach is consistent with GDPR Article 33(4), which expressly permits the provision of information "in phases" where it is not possible to provide all required information simultaneously.
We further recommend that detailed breach notification procedures — including an escalation matrix identifying key contacts at both Meridian and Skybridge, communication channels, and the format and content of initial and supplemental notifications — be set forth in a separate Schedule D (Data Breach Notification Procedures) appended to the DPA. This schedule-based approach keeps the body of the DPA clean while providing the operational detail necessary for effective incident response coordination.
D. Sub-Processor Approval Mechanics
1. Meridian Form DPA Position
Section 5 of the Meridian Form DPA requires the Processor to obtain specific prior written authorization from the Controller before engaging any sub-processor to process personal data on behalf of the Controller. Each sub-processor must be individually identified and approved by the Controller in advance of the commencement of any processing activities.
Under the Meridian Form DPA, the Controller has an absolute right to deny the engagement of any proposed sub-processor, without being required to provide a reason for such denial. There is no "reasonableness" standard applied to the Controller's decision, and no dispute resolution mechanism is provided in the event of a disagreement between the parties regarding a proposed sub-processor.
Section 5.3 of the Meridian Form DPA requires the Processor to flow down all of the data protection obligations contained in the DPA to each sub-processor by way of a written agreement. The Meridian Form DPA does not specify a particular time frame within which the Controller must respond to a sub-processor approval request, creating potential operational uncertainty if the Controller delays its review.
2. Skybridge Template Position
The Skybridge Template provides for a general written authorization model, under which the Controller provides blanket authorization for the Processor to engage sub-processors, without any requirement for prior notice to the Controller or any Controller objection right. Under the current Skybridge Template, Skybridge maintains an internal list of its sub-processors but does not share this list with controllers and does not provide notifications to controllers when new sub-processors are engaged or existing sub-processors are replaced.
This approach, while operationally convenient for Skybridge, falls short of the requirements of GDPR Article 28(2) (which requires either specific or general authorization with a right of objection) and is inconsistent with the third-party oversight expectations established by OCC Bulletin 2023-17 for critical-activity vendor relationships.
3. Market Standard
The prevailing market approach to sub-processor approval in bank-vendor DPAs is a general written authorization with prior notice and objection right model. This approach is consistent with GDPR Article 28(2), which provides that where a processor engages another processor pursuant to a general written authorization, the processor must inform the controller of any intended changes concerning the addition or replacement of sub-processors, "thereby giving the controller the opportunity to object to such changes."
In market-standard bank-vendor DPAs, the typical notice period is 30 days prior to the engagement of a new sub-processor or the replacement of an existing sub-processor. The Controller's objection right is typically limited to reasonable objections based on legitimate data protection concerns — for example, concerns about the proposed sub-processor's security posture, jurisdictional risks, or compliance history. The DPA typically provides that if the parties are unable to resolve the Controller's objection within a defined period, the Controller may terminate the affected processing activities (but not necessarily the entire DPA or subscription agreement) as its sole remedy.
The flow-down of materially equivalent data protection obligations to sub-processors by written contract is standard and is expressly required by GDPR Article 28(4). We note, however, that the requirement is for "materially equivalent" obligations — not identical obligations — recognizing that the nature of the sub-processor's activities may differ from those of the primary processor.
Specific prior written authorization for each individual sub-processor, while the most protective approach from the Controller's perspective, is disfavored by processors as operationally burdensome. This is particularly the case for template agreements intended for deployment across multiple customers, where the requirement to obtain individual approval from each controller for each sub-processor change creates significant administrative overhead and potential delays. The general authorization model with notice and objection rights achieves a reasonable balance between the Controller's oversight interests and the Processor's operational flexibility.
4. Recommendation.  We recommend that the Skybridge counter-proposal include a general written authorization model with 30-day prior written notice to the Controller before engaging any new sub-processor or replacing any existing sub-processor. The specific elements of the recommended sub-processor approval provision are as follows:
•  General Authorization: The Controller provides general written authorization for the Processor to engage sub-processors, subject to the notice and objection procedures set forth in the DPA.
•  Prior Notice: The Processor shall provide the Controller with at least 30 days' prior written notice before engaging any new sub-processor or replacing any existing sub-processor. The notice shall identify the proposed sub-processor, describe the processing activities to be performed, and identify the location(s) where personal data will be processed.
•  Objection Right: The Controller shall have the right to object to a new sub-processor within the 30-day notice period, provided that any such objection must be based on reasonable data protection grounds and must be communicated to the Processor in writing with sufficient detail to permit the Processor to evaluate and address the Controller's concerns.
•  Resolution: If the Controller's objection is not resolved within fifteen (15) days following the date of the objection, the Controller may terminate the affected processing activities (i.e., the processing activities that would be performed by the objected-to sub-processor) as its sole remedy. The Controller shall not be entitled to terminate the entire DPA or the underlying subscription agreement solely on the basis of an unresolved sub-processor objection.
•  Flow-Down: The Processor shall impose materially equivalent data protection obligations on each sub-processor by way of a written agreement. The Processor shall remain fully liable to the Controller for the acts and omissions of its sub-processors.
•  Approved Sub-Processor List: A Schedule C listing currently approved sub-processors shall be appended to the DPA. The initial Schedule C shall include: (1) Osprey Cloud Infrastructure, Inc. (IaaS/PaaS services; data center locations: Ashburn, Virginia, United States and Frankfurt, Germany); and (2) Skybridge Fintech Europe B.V. (EU data processing services; Amsterdam, Netherlands, KvK Registration No. 82104593).
We note that the existing Skybridge–Osprey Cloud DPA, dated March 1, 2024, provides evidence of Skybridge's current practice of imposing data protection obligations on sub-processors by written agreement and can be referenced (though not disclosed in full) as evidence of compliant sub-processor contracting during negotiations with BRS.
This approach satisfies the sub-contractor oversight requirements of OCC Bulletin 2023-17, is consistent with GDPR Article 28(2), and is scalable for use as a template provision across future bank client engagements.
E. Audit Rights Scope
1. Meridian Form DPA Position
Section 8 of the Meridian Form DPA grants the Controller (or its authorized third-party auditor) the right to conduct on-site audits and inspections of the Processor's facilities, systems, records, and data processing activities. The Meridian Form DPA requires only ten (10) business days' advance written notice for such audits. Notably, the Meridian Form DPA does not impose any frequency limitation on audit rights — the Controller may conduct as many audits as it deems necessary in any given year, without restriction.
Section 8.2 of the Meridian Form DPA addresses regulator access. This provision requires the Processor to permit the OCC, FDIC, CFPB, and any other applicable federal or state regulatory authority to examine the Processor in the same manner and to the same extent as if the services were being performed by the Controller itself, consistent with the examination authority established by OCC Bulletin 2023-17 and applicable banking regulations (including 12 USC § 1867 (Bank Service Company Act)).
Section 8.3 of the Meridian Form DPA provides that all audits shall be conducted at the Processor's expense, including the Processor's internal costs of facilitating and supporting the audit.
2. Skybridge Template Position
The Skybridge Template takes a significantly more limited approach to audit rights. Under Section 7 of the Skybridge Template, the Controller may request copies of Skybridge's most recent SOC 2 Type II report and may submit written questionnaires regarding Skybridge's data protection practices and security controls. The Skybridge Template does not grant the Controller any on-site audit rights.
The Skybridge Template is silent on regulatory access — it does not include any provision addressing the right of banking regulators or other governmental authorities to examine the Processor. This omission is a significant deficiency for agreements with federally chartered banks, which are required by law and regulation to ensure that their regulators have the ability to examine third-party service providers performing critical activities.
Because the Skybridge Template limits audit rights to documentary requests, no frequency limitation is necessary under the existing template framework.
3. Market Standard
In market-standard bank-vendor DPAs, on-site audit rights are a standard feature, but processors typically negotiate reasonable limitations to prevent audits from becoming unduly burdensome or disruptive to their operations. The most common approach includes the following elements:
•  Frequency: Typically limited to once per twelve (12) month period, with exceptions for audits triggered by a personal data breach, a regulatory inquiry or examination, or a material compliance concern.
•  SOC 2 Report as Primary Mechanism: It is increasingly common for bank-vendor DPAs to establish the Processor's SOC 2 Type II report as the primary audit mechanism, with on-site audit rights serving as a backstop to be exercised only if the SOC 2 report and supplemental questionnaire responses do not adequately address the Controller's concerns.
•  Notice Period: Advance written notice of 30 days is the standard notice period for on-site audits (as opposed to the 10 business days proposed by Meridian).
•  Cost Allocation: The prevailing market allocation is that audits are conducted at the Controller's expense (including the Controller's costs of engaging third-party auditors), except where the audit reveals material non-compliance by the Processor, in which case the Processor bears the cost of the audit.
•  Regulatory Access: Regulatory access must be preserved in all bank-vendor DPAs. OCC Bulletin 2023-17 and the Bank Service Company Act (12 USC § 1867) establish the OCC's authority to examine bank service providers, and this authority cannot be contractually restricted. Processors cannot limit or condition regulatory examination rights, and any attempt to do so would be inconsistent with applicable banking law and would likely raise examination findings for the Controller.
4. Recommendation.  We recommend the following approach to audit rights in the Skybridge counter-proposal:
•  On-Site Audit Right: Skybridge should accept the Controller's right to conduct on-site audits, but the DPA should limit on-site audits to once per twelve (12) month period, unless an audit is triggered by: (a) a Personal Data Breach affecting the Controller's personal data; (b) a regulatory inquiry, investigation, or examination involving the Controller or the Processor; or (c) a material non-compliance identified in the Processor's SOC 2 report or questionnaire responses.
•  SOC 2 as Primary Mechanism: The Processor may satisfy the Controller's audit requests in the first instance by providing the Processor's current SOC 2 Type II report (the most recent report, dated September 15, 2025, was issued by Graystone & Ketchum LLP and covers the audit period from October 1, 2024 through September 15, 2025) together with the Processor's written responses to the Controller's supplemental due diligence questionnaire. If the SOC 2 report and questionnaire responses do not reasonably address the Controller's concerns, the Controller may exercise its on-site audit right.
•  Notice Period: The Controller shall provide at least 30 days' advance written notice for on-site audits. The notice shall specify the scope of the proposed audit, the identity of any third-party auditors who will participate, and the proposed dates and duration of the audit.
•  Cost Allocation: On-site audits shall be conducted at the Controller's expense. Skybridge should resist the Meridian Form DPA's position that audits be conducted at the Processor's expense. The market-standard cost allocation places the cost burden on the party exercising the audit right, which is appropriate given that audits serve the Controller's oversight and compliance interests.
•  Regulatory Access: Skybridge must expressly preserve unrestricted access for the OCC, FDIC, CFPB, and any other applicable federal or state regulatory authority to examine the Processor's facilities, systems, records, and data processing activities relating to services provided to the Controller. This is a non-negotiable regulatory requirement, and Skybridge should not attempt to limit, condition, or restrict regulatory examination rights in any way. The DPA should include an affirmative covenant by the Processor to cooperate fully with any such regulatory examination and to provide all information and access reasonably requested by the applicable regulator.
•  Confidentiality: The DPA should include reasonable confidentiality protections for the benefit of the Processor during audits, including provisions ensuring that the Controller's auditors do not access or review the personal data or confidential information of other Skybridge customers during the course of an audit.
F. Data Retention and Return/Deletion
1. Meridian Form DPA Position
Section 10.1 of the Meridian Form DPA requires the Processor, upon termination or expiration of the DPA, to return and/or delete all Controller personal data within thirty (30) days. The Controller may elect whether personal data is returned (i.e., exported to the Controller in a commonly used, machine-readable format) or deleted (i.e., permanently and irreversibly destroyed using industry-standard methods).
Section 10.2 of the Meridian Form DPA requires the Processor to provide a written certification of deletion to the Controller, signed by an authorized officer of the Processor, confirming that all personal data has been deleted and that no copies, backups, or residual data remain in the Processor's possession or in the possession of any sub-processor.
The Meridian Form DPA does not include any exception for data retained pursuant to legal or regulatory obligations. Under the literal terms of the Meridian Form DPA, the Processor would be required to delete all personal data within 30 days, even if applicable law or regulation requires the Processor to retain certain records for a longer period.
2. Skybridge Template Position
Section 8.1 of the Skybridge Template provides for a 180-day post-termination retention period during which the Processor will retain the Controller's personal data in its systems. During this period, the Controller may request the return of its data. At the expiration of the 180-day period, the Processor will delete the Controller's personal data from its systems in accordance with its standard data destruction procedures.
The Skybridge Template does not require written certification of deletion. The Skybridge Template includes a broad exception permitting the Processor to retain personal data beyond the post-termination retention period to the extent necessary for "business purposes or legal obligations." This exception is vaguely defined and does not limit the categories of business purposes or legal obligations that could justify continued retention, creating potential ambiguity regarding the scope and duration of post-termination data retention.
3. Market Standard
Post-termination data retention periods of 60 to 90 days are standard in bank-vendor DPAs. This timeframe provides adequate time for the Controller to complete data migration (i.e., to export its data from the Processor's platform and import it into a successor system) and for the Processor to execute its data deletion procedures across all relevant systems, including backup and disaster recovery environments. A 30-day period, as proposed by Meridian, is shorter than operationally practical for complex data migrations, particularly where the data set includes 412,000 data subject records and 18.6 million monthly transactions. Conversely, a 180-day period, as provided in the Skybridge Template, is longer than market standard and may raise concerns from Controllers about the duration of their data's exposure to Processor's systems after the relationship has ended.
Written certification of deletion is increasingly common in bank-vendor DPAs and is a reasonable expectation for critical-activity vendor relationships. The certification provides the Controller with documentary evidence of compliance for its TPRM files and regulatory examination materials.
A narrow exception for data retained pursuant to specific legal or regulatory obligations (e.g., record retention requirements under banking regulations, tax law, or court orders) is acceptable and appropriate. However, the exception should be narrowly defined — limited to retention required by applicable law or regulation — and should not extend to vaguely defined "business purposes." Any data retained pursuant to such an exception should remain subject to the DPA's confidentiality and security obligations for the duration of the retention.
4. Recommendation.  We recommend the following approach to data retention and return/deletion in the Skybridge counter-proposal:
•  Post-Termination Retention Period: Upon termination or expiration of the DPA, the Processor shall retain the Controller's personal data for a period of ninety (90) days to allow the Controller to complete data migration. During this period, the Processor shall make the Controller's personal data available for export in a commonly used, machine-readable format upon the Controller's reasonable request.
•  Deletion and Certification: Upon the expiration of the 90-day retention period, the Processor shall permanently and irreversibly delete all remaining Controller personal data from all of the Processor's systems (including backup and disaster recovery environments) and from the systems of all sub-processors. Upon completion of deletion, the Processor shall provide the Controller with a written certification of deletion, signed by an authorized representative of the Processor, confirming that all personal data has been deleted and that no copies or residual data remain.
•  Narrow Legal Hold Exception: Notwithstanding the foregoing, the Processor may retain Controller personal data to the extent required by applicable law or regulation (e.g., regulatory record retention requirements, court orders, or valid legal hold obligations). Any data retained pursuant to this exception shall remain subject to the DPA's confidentiality and security obligations for the duration of such retention. The Processor shall notify the Controller of any data retained pursuant to this exception, identifying the legal or regulatory basis for the retention and the categories of data retained.
The 90-day period provides sufficient time for Skybridge's engineering team — led by VP of Engineering Sanjay Dhillon — to execute the data migration and deletion process across all production, backup, and disaster recovery environments while remaining within the market-standard range. This timeline should also be coordinated with the underlying SaaS subscription agreement's transition-out provisions to ensure operational alignment.
G. Insurance Requirements
1. Meridian Form DPA Position
Section 14 of the Meridian Form DPA includes detailed insurance requirements applicable to the Processor. The Meridian Form DPA requires the Processor to maintain technology errors and omissions ("Tech E&O") and cyber-liability insurance throughout the term of the DPA with the following minimum coverage levels: (a) $15 million per occurrence; and (b) $30 million in the aggregate.
Section 14.2 of the Meridian Form DPA requires the Processor to name the Controller as an additional insured under the Processor's cyber-liability policy. Section 14.3 requires the Processor to provide the Controller with a certificate of insurance evidencing the required coverage on an annual basis. Section 14.4 requires the Processor to maintain the required insurance coverage for three (3) years following termination of the DPA (i.e., a 3-year tail coverage requirement).
2. Skybridge Template Position
The Skybridge Template does not include any insurance requirements. The DPA is silent on the Processor's obligation to maintain insurance coverage, the minimum coverage levels, and the Controller's right to request evidence of coverage. This omission is consistent with many SaaS provider DPA templates, which tend to address insurance in the underlying commercial agreement rather than in the DPA, but it represents a gap for bank-grade agreements where insurance requirements are a standard TPRM component.
3. Market Standard
Cyber-liability insurance requirements are standard in bank-vendor DPAs, particularly for critical-activity vendor relationships. The OCC Bulletin 2023-17 does not mandate specific insurance levels, but it expects banks to assess the financial condition and insurance coverage of third-party vendors and to include appropriate contractual provisions addressing insurance.
For deals of this ACV (approximately $2.74 million per year), per-occurrence coverage of $5 million to $15 million is typical in market-standard bank-vendor DPAs. The most common per-occurrence threshold is $10 million. The $15 million per-occurrence minimum proposed by Meridian is at the upper end of the market range for a deal of this size and may reflect Meridian's general form template rather than a position calibrated to the specific ACV of the Skybridge engagement.
Additional insured status is sometimes requested by bank clients but is less commonly granted by processors. M