CALDERWOOD & HARKNESS LLP
1735 Market Street, Suite 2800 Philadelphia, PA 19103
MEMORANDUM
PRIVILEGED AND CONFIDENTIAL — ATTORNEY WORK PRODUCT
February 10, 2026
TO:
Thomas Elridge, General Counsel / Chief Privacy Officer, Skybridge Fintech Ltd. Rebecca Muñoz, Chief Information Security Officer, Skybridge Fintech Ltd.
FROM:
Priscilla Wynn, Lead Associate, Privacy & Data Security Group, Calderwood & Harkness LLP
RE:
Customization Guide — Adapting the Meridian-Negotiated Data Processing Agreement as Skybridge's Standard Bank-Grade Template for Future Bank Clients
MATTER NO.: 1009-00004
Right-click to update Table of Contents
I. PURPOSE AND BACKGROUND
This memorandum provides practical, section-by-section instructions for Skybridge Fintech Ltd. ("Skybridge" or "SBF") to use the Data Processing Agreement negotiated with Meridian Federal Savings Bank ("Meridian") as the standard bank-grade DPA template for future FDIC-insured bank and credit union clients. The Meridian DPA was executed on February 15, 2026, and represents the culmination of approximately four months of intensive negotiation between this firm and Blackwell, Raines & Stoddard LLP, counsel for Meridian. The resulting agreement reflects market-standard terms acceptable to a $6.1 billion federally chartered savings bank subject to oversight by the Office of the Comptroller of the Currency ("OCC"), the Federal Deposit Insurance Corporation ("FDIC"), and the Consumer Financial Protection Bureau ("CFPB"). We believe the Meridian DPA establishes a durable and defensible baseline that will be well-received by similarly situated bank clients.
The template DPA is governed by the laws of the State of Delaware, consistent with Skybridge's state of incorporation and principal office location. The appended Standard Contractual Clauses ("SCCs"), adopted pursuant to the European Commission's Implementing Decision (EU) 2021/914, are governed by the law of the Netherlands per Clause 17, reflecting the establishment of Skybridge Fintech Europe B.V. in Amsterdam.
The DPA consists of the main body agreement and the following schedules and annexes:
• Schedule A — Description of Processing (data subjects, categories of personal data, processing purposes, duration, and volume)
• Schedule B — Security Measures (technical and organizational measures implemented by Skybridge)
• Schedule C — Approved Sub-Processor List
• Schedule D — Data Breach Notification Procedures (escalation contacts, timelines, and reporting obligations)
• Standard Contractual Clauses Package — Module 2 (Controller-to-Processor, governing transfers from bank client to Skybridge) and Module 3 (Processor-to-Sub-processor, governing transfers from Skybridge to its sub-processors), together with Annexes I (Description of Transfer), II (Technical and Organizational Measures), and III (List of Sub-processors)
This guide categorizes each provision of the template DPA as either "standard" (to remain unchanged across all bank clients) or "customer-specific" (requiring adaptation for each new engagement). For customer-specific provisions, we provide detailed instructions on how to populate the relevant fields and, where applicable, negotiation guidance on common bank requests and recommended Skybridge positions. The goal of this framework is to enable Skybridge to deploy the template DPA efficiently in future bank engagements while preserving the substantive protections achieved in the Meridian negotiation.
II. OVERVIEW OF THE TEMPLATE STRUCTURE
Before proceeding to the provision-by-provision analysis, it is helpful to summarize the overall structure of the template DPA. The main body of the agreement is organized into the following sections:
1. Definitions — GDPR-aligned definitions of key terms used throughout the agreement
2. Scope of Processing — Description of the processing activities and the relationship between the parties
3. Processor Obligations — Core obligations of Skybridge as Processor, including duty to process only on documented instructions, confidentiality, and personnel obligations
4. Controller Obligations — Acknowledgements and obligations of the bank client as Controller
5. Sub-Processors — Framework for Skybridge's engagement of sub-processors, including the general authorization model, notice requirements, and flow-down obligations
6. Security Measures — Skybridge's technical and organizational measures, with detailed specifications in Schedule B
7. Data Breach Notification — Notification timelines, procedures, and cooperation obligations, with operational details in Schedule D
8. Audit Rights — Controller and regulator audit rights, including the SOC 2 report mechanism
9. Data Subject Rights — Processor cooperation with data subject access, correction, deletion, and portability requests
10. Liability and Indemnification — Liability caps, consequential damages exclusion, and indemnification obligations
11. International Data Transfers and SCCs — Framework for cross-border transfers, incorporation of SCCs, and supplementary measures including the EU-US Data Privacy Framework
12. Term and Termination — DPA term aligned with the SaaS subscription agreement, termination rights, and survival provisions
13. Data Return/Deletion — Post-termination obligations regarding return and secure deletion of personal data
14. Insurance — Processor's obligation to maintain cyber-liability insurance coverage
15. General Provisions — Miscellaneous provisions including notices, amendments, severability, entire agreement, and counterparts
The Schedules (A through D) and the SCC package (Modules 2 and 3, Annexes I through III) supplement the main body and contain both standard and customer-specific content as described in detail in Sections III and IV below.
It is important to note that the template was designed for the specific processing relationship in which Skybridge acts as Processor and the bank client acts as Controller. This designation reflects the commercial reality of Skybridge's SaaS platform "SBF Core," which provides real-time payment processing, anti-fraud analytics, and regulatory reporting services to bank clients. Skybridge processes personal data belonging to the bank's accountholders on behalf of and under the instructions of the bank. This Controller-Processor designation should not be altered in future deployments of the template, as it accurately reflects the parties' respective roles and is consistent with both GDPR Article 28 and the expectations of U.S. banking regulators regarding third-party service provider arrangements.
III. STANDARD PROVISIONS — RETAIN UNCHANGED ACROSS ALL BANK CLIENTS
The following provisions of the template DPA should remain substantively unchanged in each new bank client engagement. These provisions reflect either (a) legally mandated formulations (e.g., GDPR Article 28 requirements, SCC clauses), (b) Skybridge's actual operational practices and security posture, or (c) carefully negotiated positions that represent the appropriate allocation of risk for a processor in Skybridge's position. Departures from these standard provisions should be treated as exceptions requiring internal escalation and, where appropriate, review by Calderwood & Harkness.
A. Definitions
The definitions section of the template DPA includes GDPR-aligned definitions of the following key terms: "Personal Data," "Processing," "Personal Data Breach," "Data Subject," "Controller," "Processor," "Sub-processor," and "Supervisory Authority." These definitions were drafted to be consistent with the definitions in Article 4 of Regulation (EU) 2016/679 (the GDPR) and are widely recognized as the international standard for data processing agreements. They should remain unchanged across all bank clients.
Of particular importance is the definition of "Applicable Data Protection Laws," which is intentionally drafted to be broad and inclusive. The definition encompasses the following laws and regulations:
• The Gramm-Leach-Bliley Act ("GLBA") and its implementing regulations, including Regulation P (12 CFR Part 1016) and the FTC Safeguards Rule (16 CFR Part 314)
• The General Data Protection Regulation (Regulation (EU) 2016/679) ("GDPR")
• The California Consumer Privacy Act, as amended by the California Privacy Rights Act ("CCPA/CPRA") (Cal. Civ. Code §§ 1798.100–1798.199.100)
• The New Jersey Data Privacy Act (S3377), effective January 15, 2026
• All other applicable federal, state, and local data protection and privacy laws and regulations
This breadth of coverage is a deliberate design choice. Skybridge's client base spans multiple states, and the bank clients' accountholders are located throughout the United States (and, in certain cases, in the European Union). By maintaining a comprehensive definition of Applicable Data Protection Laws, Skybridge ensures that the DPA provides adequate contractual coverage regardless of the specific jurisdictional footprint of any individual bank client. Narrowing this definition to accommodate a particular client's preference would create risk for Skybridge in the event of a regulatory inquiry or enforcement action under a law inadvertently excluded from the definition.
B. Processor Obligations (Core Processing Terms)
The core processing terms in the main body of the DPA establish the fundamental obligations of Skybridge as Processor. These provisions include:
• Instruction-Bound Processing. Skybridge shall process personal data only on documented instructions from the Controller, including with respect to transfers of personal data to a third country or an international organization, unless required to do so by applicable law to which Skybridge is subject. In such a case, Skybridge shall inform the Controller of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest. This provision directly implements Article 28(3)(a) of the GDPR and is a cornerstone of the Controller-Processor relationship.
• Confidentiality Obligations. Skybridge shall ensure that persons authorized to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. This obligation extends to all Skybridge personnel, including employees, contractors, and temporary staff who may have access to personal data in the course of performing services under the SaaS subscription agreement.
• Cooperation with Regulatory Authorities. Skybridge shall make available to the Controller all information necessary to demonstrate compliance with the obligations laid down in the DPA and shall allow for and contribute to audits, including inspections, conducted by the Controller or another auditor mandated by the Controller.
These provisions reflect the mandatory requirements of Article 28 of the GDPR and are considered non-negotiable elements of any adequate data processing agreement. They should not be altered for any bank client, regardless of the client's charter type, size, or regulatory profile. Any bank counsel suggesting modifications to these provisions should be directed to the language of Article 28 itself.
C. Security Measures (Schedule B — Standard Content)
Schedule B of the template DPA sets forth the technical and organizational security measures that Skybridge has implemented to protect personal data processed through SBF Core. These measures reflect Skybridge's actual security posture as of the date of this memorandum and are validated by independent audit. The following measures are specified in Schedule B and should remain standard across all bank clients:
• SOC 2 Type II Certification. Skybridge maintains a current SOC 2 Type II report covering the Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy. The current report was issued by Graystone & Ketchum LLP and covers the audit period from October 1, 2024 through September 15, 2025. This report is refreshed annually, and the next audit cycle is expected to commence in October 2025, with a new report anticipated in early 2026.
• Encryption at Rest. All personal data stored within SBF Core and its associated databases and storage systems is encrypted using AES-256 encryption. This applies to both primary and backup storage, including data stored in Osprey Cloud data centers.
• Encryption in Transit. All personal data transmitted between SBF Core components, between Skybridge and its sub-processors, and between Skybridge and bank clients is encrypted using TLS 1.2 or higher. Skybridge does not support TLS versions below 1.2.
• Multi-Factor Authentication (MFA). MFA is required for all administrative access to SBF Core, including access by Skybridge personnel, sub-processors, and bank client administrators. MFA is enforced using hardware tokens or authenticator applications; SMS-based MFA is not permitted for administrative access.
• Annual Penetration Testing. Skybridge engages Ironvault Security Group LLC (11710 Plaza America Drive, Suite 400, Reston, VA 20190) to conduct annual penetration testing of SBF Core and its supporting infrastructure. Test results and remediation plans are available to bank clients upon request as part of the audit rights framework.
• Incident Response Plan. Skybridge maintains a written incident response plan that is tested at least annually through tabletop exercises. The plan addresses detection, containment, eradication, recovery, and post-incident review procedures.
• Employee Security Training. All Skybridge personnel with access to personal data are required to complete security awareness training upon hire and annually thereafter. Training covers phishing recognition, data handling procedures, incident reporting, and acceptable use policies.
• Physical Security. Physical security at Osprey Cloud data centers (Ashburn, VA and Frankfurt, Germany) includes 24/7 on-site security personnel, biometric access controls, CCTV surveillance, and environmental controls (fire suppression, climate control, uninterruptible power supply, and backup generators).
Important Note on Customization Requests: The security measures set forth in Schedule B should remain standard across all bank clients. They represent Skybridge's actual security posture and are the measures that have been independently audited under the SOC 2 Type II framework. If any bank client requests security measures that exceed those specified in Schedule B — for example, requesting FIPS 140-2 validated cryptographic modules, specific key management procedures beyond those currently implemented, or more frequent penetration testing — such requests should be escalated to CISO Rebecca Muñoz and VP of Engineering Sanjay Dhillon for a feasibility review before any contractual commitment is made. Committing to security measures that Skybridge cannot operationally deliver would expose Skybridge to breach of contract claims and potential regulatory scrutiny.
D. Sub-Processor Framework (General Authorization Model)
The template DPA employs a general written authorization model for sub-processor engagement, which is one of the two models expressly permitted under Article 28(2) of the GDPR. Under this framework:
• Skybridge has general written authorization from the Controller to engage sub-processors for the purpose of performing its obligations under the SaaS subscription agreement and the DPA.
• Skybridge shall provide the Controller with 30 calendar days' prior written notice before engaging any new sub-processor or replacing an existing sub-processor. Such notice shall identify the proposed sub-processor, describe the processing activities to be performed, and specify the location(s) of processing.
• The Controller shall have the right to object to the engagement of a new sub-processor during the 30-day notice period. If the Controller objects on reasonable grounds related to data protection, the parties shall discuss the objection in good faith. If the parties are unable to resolve the objection within 15 business days following the Controller's objection, the Controller may terminate the DPA and the underlying SaaS subscription agreement with respect to the affected processing activities.
• Skybridge shall impose on each sub-processor, by way of a written contract, data protection obligations equivalent to those set out in the DPA. Skybridge shall remain fully liable to the Controller for the performance of the sub-processor's obligations.
This general authorization framework — as opposed to a specific prior consent model requiring the Controller's affirmative approval before each sub-processor engagement — is the market standard for SaaS processors serving multiple bank clients. Switching to a specific prior consent model would be operationally burdensome for Skybridge, as it would require obtaining individual approvals from every existing bank client before onboarding any new sub-processor, potentially delaying critical infrastructure or service improvements. The 30-day notice and objection mechanism provides bank clients with meaningful oversight and control while preserving Skybridge's operational flexibility.
This framework should remain unchanged across all bank clients. If a bank's counsel or TPRM team requests a specific prior consent model, explain the operational rationale for the general authorization approach and emphasize that the 30-day notice period and objection right provide equivalent protections.
E. Data Subject Rights Cooperation
The template DPA includes a standard provision obligating Skybridge, as Processor, to assist the Controller in responding to requests from data subjects exercising their rights under Applicable Data Protection Laws. These rights include, but are not limited to, the right of access, the right to rectification or correction, the right to erasure or deletion, the right to restriction of processing, the right to data portability, and the right to object to processing. Skybridge shall implement appropriate technical and organizational measures to assist the Controller in fulfilling its obligations to respond to such requests, taking into account the nature of the processing.
This provision implements Article 28(3)(e) of the GDPR and is consistent with similar requirements under CCPA/CPRA and the NJ Data Privacy Act. It is a standard provision that requires no customization for individual bank clients. The operational procedures for processing data subject rights requests are documented in Skybridge's internal standard operating procedures and are consistent across all client engagements.
F. DPIA Cooperation
The template DPA includes a provision requiring Skybridge to assist the Controller, at the Controller's reasonable request, with Data Protection Impact Assessments ("DPIAs") required under Article 35 of the GDPR or analogous assessments required under other Applicable Data Protection Laws. Skybridge shall provide such information regarding its processing activities as is reasonably necessary for the Controller to conduct the DPIA, taking into account the nature of the processing and the information available to Skybridge.
This is a standard provision applicable to all bank clients. While DPIAs are a GDPR-specific requirement, several U.S. state privacy laws (including the CPRA and the NJ Data Privacy Act) include analogous risk assessment requirements. Additionally, banking regulators increasingly expect banks to conduct risk assessments of their third-party service provider relationships as part of their third-party risk management programs (see OCC Bulletin 2023-17 and FFIEC IT Examination Handbook, "Outsourcing Technology Services" booklet). This provision should remain unchanged.
G. Governing Law
The governing law provisions of the template DPA are structured as follows:
• Main Body DPA: Governed by the laws of the State of Delaware, without regard to its conflicts of law principles.
• Standard Contractual Clauses (Clause 17): Governed by the law of the Netherlands. This choice of law is fixed by the establishment of Skybridge Fintech Europe B.V. in Amsterdam, the Netherlands, and reflects the requirement under the SCCs that the governing law be the law of an EU Member State.
These governing law provisions should not be altered for any bank client. If a bank requests that the DPA be governed by the law of its own state (e.g., New York, New Jersey, or California), the appropriate response is to explain that Delaware law is used to maintain template consistency across Skybridge's client base and that the substantive data protection obligations in the DPA are not materially affected by the choice of governing law, as the DPA is designed to comply with all Applicable Data Protection Laws regardless of the governing law of the agreement itself. With respect to the SCCs, the governing law is legally required to be the law of an EU Member State, and the Netherlands was selected based on Skybridge's EU establishment. This is not negotiable.
It bears noting that the dispute resolution clause in the main body DPA provides for exclusive jurisdiction in the courts of the State of Delaware (Court of Chancery or, if that court declines jurisdiction, the Superior Court of the State of Delaware) or the United States District Court for the District of Delaware. The SCCs contain their own dispute resolution provisions (Clause 18), which provide for jurisdiction in the courts of an EU Member State (the Netherlands). These provisions should also remain unchanged.
H. Insurance Requirements
The template DPA requires Skybridge, as Processor, to maintain cyber-liability insurance with per-occurrence coverage of no less than $10,000,000 (ten million dollars) throughout the term of the DPA and for a period of one year following termination. The current policy details are as follows:
• Carrier: Bastion Mutual Insurance Company
• Policy Number: CYB-2025-04821
• Coverage: $10,000,000 per occurrence / $20,000,000 aggregate
• Broker: Kestrel Risk Advisors LLC
Skybridge is also required to provide the Controller with a certificate of insurance upon request and to notify the Controller promptly of any material reduction in coverage or cancellation of the policy.
The $10,000,000 per-occurrence minimum should be treated as the standard across all bank clients. It represents a meaningful level of coverage that is consistent with market expectations for a fintech processor handling sensitive financial data. If a bank client requests a higher insurance minimum (e.g., $15M or $20M per occurrence), such a request should trigger an internal review involving Thomas Elridge and Kestrel Risk Advisors to assess whether additional coverage is available, the premium impact of increasing coverage, and whether the requested minimum is commercially justified given the scope of processing and the client's ACV. Do not agree to insurance minimums exceeding the $20M aggregate limit without first confirming that such coverage is obtainable.
I. Post-Termination Data Retention and Return/Deletion
The template DPA provides that Skybridge shall retain personal data processed on behalf of the Controller for the duration of the SaaS subscription agreement plus 90 calendar days following termination or expiration of the subscription agreement (the "Post-Termination Period"). During the Post-Termination Period, the Controller may request the return of its personal data in a structured, commonly used, and machine-readable format, or may instruct Skybridge to securely delete all personal data.
Upon expiration of the Post-Termination Period without instruction from the Controller, Skybridge shall securely delete all personal data unless retention is required by applicable law. Skybridge shall confirm deletion in writing upon the Controller's request. Any legally mandated retention shall be limited to the minimum period and scope required by law, and the retained data shall remain subject to the confidentiality and security obligations of the DPA.
This 90-day post-termination retention and return/deletion framework should remain standard across all bank clients. The 90-day period provides sufficient time for the bank to complete data migration to an alternative service provider or to its own systems. Shortening this period (e.g., to 30 days) would create operational risk for both parties, as complex data migration projects involving financial transaction data often require more than 30 days to complete. Extending the period beyond 90 days is generally unnecessary and would increase Skybridge's data retention obligations and associated costs.
J. Standard Contractual Clauses — Core Structure
The SCC package appended to the template DPA consists of two modules:
• Module 2 (Controller-to-Processor): Governing transfers of personal data from the bank client (Controller/Data Exporter) to Skybridge (Processor/Data Importer). This module applies to transfers of personal data of EU-resident accountholders from the bank client to Skybridge for processing via SBF Core.
• Module 3 (Processor-to-Sub-processor): Governing transfers of personal data from Skybridge (Processor/Data Exporter) to its sub-processors (Sub-processor/Data Importer), specifically Osprey Cloud Infrastructure, Inc. (IaaS/PaaS services) and Skybridge Fintech Europe B.V. (EU data processing).
The SCC clauses themselves are prescribed by the European Commission's Implementing Decision (EU) 2021/914 of June 4, 2021, and cannot be modified by the parties. This is a legal requirement; any alteration to the substantive clauses of the SCCs would render them invalid as a transfer mechanism under Article 46(2)(c) of the GDPR. Only the Annexes (Annex I — Description of Transfer, Annex II — Technical and Organizational Measures, and Annex III — List of Sub-processors) are customized to reflect the specific transfer arrangement. The customization of these Annexes is addressed in Section IV.H below.
Clause 17 Governing Law: The SCCs are governed by the law of the Netherlands. This choice is standard across all Skybridge bank clients, as it is determined by the location of Skybridge's EU establishment (Skybridge Fintech Europe B.V., Amsterdam, the Netherlands), and should not be altered.
Supplementary Measure — EU-US Data Privacy Framework. The template DPA references Skybridge's self-certification under the EU-US Data Privacy Framework ("DPF"), certification number DPF-2025-03912, effective July 1, 2025. The DPF provides an additional legal basis for transatlantic personal data transfers following the European Commission's adequacy decision of July 10, 2023. However, the SCCs are retained as the primary transfer mechanism, and the DPF certification is positioned as a supplementary measure. This approach provides resilience in the event of a future legal challenge to the DPF (analogous to the Schrems I and Schrems II decisions that invalidated the Safe Harbor framework and the Privacy Shield, respectively). The DPF certification should be referenced in all bank client DPAs as a supplementary measure, but it does not replace the SCCs.
IV. CUSTOMER-SPECIFIC PROVISIONS — REQUIRING ADAPTATION FOR EACH BANK CLIENT
The following provisions of the template DPA contain elements that must be adapted for each new bank client engagement. For each provision, we identify the customer-specific elements, provide instructions for populating those elements, and offer negotiation guidance where applicable.
A. Party Identification and Recitals
The opening provisions of the DPA, including the preamble and recitals, contain the following customer-specific elements that must be updated for each new bank client:
Bank Client Identification:
• Replace "Meridian Federal Savings Bank" with the new bank client's full legal name, including entity type (e.g., "a national banking association organized under the laws of the United States," "a state-chartered commercial bank organized under the laws of [State]," "a federal credit union chartered by the National Credit Union Administration").
• Include the bank's charter number, if applicable (e.g., OCC charter number for national banks, state charter number for state-chartered banks, NCUA charter number for federal credit unions).
• Include the bank's FDIC certificate number, if applicable.
• Insert the bank's headquarters address.
Regulatory Supervisor References in Recitals:
• Update the recitals to reference the bank client's primary federal and state regulatory supervisors based on the client's charter type. The Meridian DPA references the OCC, FDIC, and CFPB as Meridian's regulatory supervisors. The appropriate references for other charter types are addressed in Section IV.I below.
Contact Information for Notice and Communication:
• Update the name, title, mailing address, email address, and telephone number of the Controller's designated contacts for notice and communication purposes. The template includes designated contacts for the following roles:
• General Counsel (for legal notices and DPA amendments)
• Chief Compliance Officer (for regulatory compliance matters)
• VP of Third-Party Risk Management or equivalent (for audit and vendor management matters)
For reference, the Meridian-specific contacts that should be replaced are:
• General Counsel: Vanessa Hartwell, Meridian Federal Savings Bank, 900 Broad Street, Suite 1200, Newark, NJ 07102
• Chief Compliance Officer: Andrea Sokolov, same address
• VP of Third-Party Risk Management: Marcus Tibaldi, same address
Skybridge's own contact information in the DPA (Thomas Elridge, General Counsel / Chief Privacy Officer, 4100 Silverside Road, Suite 310, Wilmington, DE 19810) remains standard across all clients.
B. Liability Cap
The template DPA includes a liability cap that applies to Skybridge's aggregate liability under the DPA (excluding liability that cannot be limited by applicable law). The cap is structured using a formula with a floor:
Formula (Standard):
The aggregate liability of the Processor under this Agreement shall not exceed the greater of: (a) five million dollars ($5,000,000); or (b) two times (2×) the total fees paid or payable by the Controller to the Processor under the SaaS Subscription Agreement in the twelve (12) month period immediately preceding the event giving rise to the claim.
The formula itself is a standard provision and should not be altered. The customer-specific element is the Annual Contract Value ("ACV"), which determines the effective cap for each client as follows:
Application — Meridian Example:
Meridian's ACV under the SaaS Subscription Agreement is $2,740,000 per year. Applying the formula: 2 × $2,740,000 = $5,480,000. Because $5,480,000 exceeds the $5,000,000 floor, the effective liability cap for the Meridian engagement is $5,480,000.
Guidance for Smaller Clients (ACV Below $2.5M):
For bank clients with ACVs below $2,500,000, the $5,000,000 floor will apply as the effective cap, because 2× the ACV will be less than $5,000,000. For example, a bank with an ACV of $1,800,000 would have a 2× amount of $3,600,000, which is below the $5,000,000 floor; the effective cap would therefore be $5,000,000. This floor is by design — it ensures that Skybridge's liability exposure under the DPA is meaningful and commensurate with the risk profile of processing financial data, even for smaller engagements.
Guidance for Larger Clients (ACV Above $5.0M):
For bank clients with significantly higher ACVs (e.g., $10,000,000 or more), the 2× formula would produce a correspondingly larger cap. If a bank with a high ACV seeks to negotiate the formula (e.g., requesting a 3× multiplier) or seeks a cap above $20,000,000, the matter should be escalated to Thomas Elridge and Kevin Ostrowski (Calderwood & Harkness LLP) before any agreement is reached. A liability cap exceeding $20,000,000 may exceed Skybridge's current cyber-insurance aggregate coverage limit under the Bastion Mutual policy ($20,000,000 aggregate) and would expose Skybridge to uninsured liability. In such cases, the options include (i) negotiating a lower multiplier or a fixed dollar cap, (ii) increasing Skybridge's insurance coverage (with associated premium impact), or (iii) negotiating a risk-sharing mechanism.
C. Indemnification
The template DPA includes the following indemnification structure:
Standard Structure:
Skybridge, as Processor, shall defend, indemnify, and hold harmless the Controller, its officers, directors, employees, and agents from and against any third-party claims, demands, suits, actions, or proceedings (collectively, "Claims") arising from or relating to Skybridge's breach of the DPA, including regulatory fines and penalties imposed on the Controller to the extent (a) such fines or penalties are attributable to Skybridge's breach, (b) applicable law permits indemnification for such fines or penalties, and (c) the indemnification obligation is subject to the liability cap set forth in the DPA.
This one-way indemnification from Processor to Controller is appropriate given the Controller-Processor relationship and should be maintained as the standard position. The following negotiation points commonly arise in bank negotiations:
Mutual Indemnification Requests:
Bank clients and their counsel frequently request mutual indemnification — that is, they seek an obligation from Skybridge to indemnify the bank and an obligation from the bank to indemnify Skybridge. Skybridge's template intentionally provides one-way indemnification from Processor only. Controller indemnification obligations (i.e., the bank's obligation to indemnify Skybridge for claims arising from the bank's own conduct) belong in the SaaS subscription agreement, not in the DPA. The DPA is a data protection instrument, and the indemnification provisions should be limited to data protection-related claims arising from the Processor's conduct. Resist requests to insert mutual indemnification into the DPA, and direct bank counsel to the SaaS subscription agreement for any Controller indemnification obligations.
Regulatory Fines Carve-Out from Liability Cap:
Bank clients, particularly those with robust TPRM programs, may seek to carve out regulatory fines from the liability cap — that is, they may argue that fines imposed by the OCC, FDIC, CFPB, or a data protection authority should be recoverable from Skybridge without dollar limitation. The Meridian-negotiated position, which should be maintained, is that regulatory fines are included within the liability cap, subject to applicable law permitting indemnification for fines. This position recognizes that unlimited indemnification for regulatory fines would represent an unbounded risk for Skybridge and is inconsistent with the purpose of a liability cap. If a bank insists on a fines carve-out, offer as a compromise to create a separate, higher sub-cap specifically for regulatory fines (e.g., the greater of $7.5M or 3× fees), subject to approval from Thomas Elridge.
Indemnification for Direct Damages Beyond Third-Party Claims:
Some bank counsel may seek to extend the indemnification obligation to cover direct damages suffered by the bank, rather than limiting indemnification to third-party claims. The template intentionally limits indemnification to third-party claims (i.e., claims brought against the bank by third parties, including regulators, data subjects, and contractual counterparties) to avoid overlap with the direct liability provisions in the SaaS subscription agreement. Direct damages (e.g., costs of remediation, business interruption, reputational harm) are addressed through the direct liability and limitation of liability provisions, not through indemnification. Expanding indemnification to cover direct damages would effectively create a second pathway for recovering the same types of losses and could undermine the liability cap. This position should be maintained.
Escalation: If a bank's counsel insists on broader indemnification terms that deviate from the positions described above, the matter should be flagged for Calderwood & Harkness review before any concession is made. Indemnification provisions in data processing agreements are among the most heavily negotiated terms in the banking sector, and deviations from Skybridge's template position may have cascading effects across the client base if other banks learn of the concession through benchmarking or RFP processes.
D. Breach Notification Timeline
The template DPA requires Skybridge to notify the Controller of a Personal Data Breach within 48 hours from the time Skybridge becomes aware of the breach. Notification must be provided to the Controller's designated contacts as set forth in Schedule D and must include, to the extent known at the time of notification, the information specified in Article 33(3) of the GDPR and any additional information required by Applicable Data Protection Laws.
Regulatory Context:
The 48-hour vendor-to-bank notification timeline was carefully calibrated during the Meridian negotiation to account for the cascading notification obligations applicable to FDIC-insured banks. Under the FDIC/OCC Computer-Security Incident Notification Rule (12 CFR Part 53, effective May 1, 2022), banks are required to notify their primary federal regulator within 36 hours of the bank determining that a "notification incident" has occurred. The 48-hour vendor-to-bank timeline provides the bank with a buffer period to receive the notification from Skybridge, assess the incident, determine whether it constitutes a "notification incident" under 12 CFR Part 53, and make its own regulatory notification within the 36-hour window. This cascading timeline is well understood by banking regulators and bank TPRM teams.
Customer-Specific Considerations:
Certain bank clients may request a shorter notification timeline, such as 24 hours or "without undue delay." The 48-hour timeline should be treated as Skybridge's standard, and Skybridge should not agree to any notification timeline shorter than 36 hours without CISO Rebecca Muñoz confirming that such a shorter timeline is operationally feasible. Incident investigation, scoping, and initial notification preparation require time, and committing to an unrealistically short timeline could result in premature or incomplete notifications that create more confusion than clarity for the bank's incident response team.
If a bank requests 24-hour notification, the recommended negotiation approach is to explain the regulatory context described above, emphasize that 48 hours is the market standard for vendor-to-bank breach notification, and offer as a compromise a "best efforts" qualifier for the initial 24-hour period (e.g., "Processor shall use best efforts to notify Controller within 24 hours and shall in any event notify Controller within 48 hours"). If the bank accepts this formulation, it should be approved by Thomas Elridge before inclusion.
Schedule D — Escalation Matrix:
Schedule D contains the detailed breach notification procedures, including the escalation matrix identifying specific contacts at both Skybridge and the bank client. The Skybridge-side contacts are standard (CISO Rebecca Muñoz → GC Thomas Elridge → bank's designated contacts) and do not change between clients. The bank-side contacts must be updated for each new engagement to include the bank's CCO, CISO, TPRM lead, General Counsel, and outside counsel. These contacts are discussed further in Section IV.G below.
E. Audit Rights
The template DPA establishes the following audit rights framework:
Standard Framework:
The Controller (or its authorized representative, including its internal or external auditors) and the Controller's primary federal and state regulatory supervisors (including the OCC, FDIC, CFPB, and applicable state banking departments) may audit the Processor's processing activities, facilities, and systems to verify compliance with the DPA. The following conditions apply:
• Advance Notice: 30 calendar days' advance written notice to the Processor (except in the case of a regulatory examination, which may occur without prior notice to the Processor).
• Frequency: No more than once per 12-month period under ordinary circumstances.
• Cost: At the Controller's expense (including costs of the Controller's auditors, travel, and related expenses).
• SOC 2 Report Mechanism: The Processor may satisfy audit requests by providing its current SOC 2 Type II report (issued by Graystone & Ketchum LLP) together with supplemental responses to the Controller's specific questions or questionnaire.
Exceptions — Unlimited Audit Rights:
The once-per-12-month frequency limitation does not apply in the following circumstances:
• A Personal Data Breach has occurred that affects the Controller's personal data.
• A regulatory inquiry, investigation, examination, or enforcement action directed at the Controller or the Processor requires additional audit activity.
• The Controller has reasonable grounds to believe that the Processor is not in compliance with its obligations under the DPA.
In these circumstances, the Controller (and its regulators) may conduct additional audits on reasonable notice, and the Processor shall cooperate fully.
Regulator Access — Non-Negotiable:
The provision granting the bank client's regulatory supervisors direct access to examine Skybridge's operations, records, and facilities cannot be restricted, qualified, or removed from the DPA. OCC Bulletin 2023-17 ("Third-Party Relationships: Risk Management Guidance") and the Federal Financial Institutions Examination Council ("FFIEC") Guidance on Technology Service Providers require that bank regulators retain the contractual right to directly access and examine the bank's critical service providers. Failure to include this provision in the DPA would likely be identified as a deficiency in the bank's TPRM program during a regulatory examination and could result in a Matter Requiring Attention ("MRA") or a Matter Requiring Immediate Attention ("MRIA") from the bank's primary regulator. This provision must remain in every bank client DPA, regardless of the bank's charter type.
Customer-Specific Considerations:
The following negotiation points commonly arise:
• More Frequent Audits. Some banks may negotiate for more frequent audits (e.g., semi-annual). This request should be resisted. Annual auditing is the market standard for processor audit rights, and the SOC 2 Type II report — which covers a 12-month audit period and is independently audited — should satisfy the vast majority of audit requirements. If a bank insists on semi-annual audits, offer as a compromise an interim update letter from Skybridge's CISO confirming no material changes to security posture since the most recent SOC 2 report, supplemented by responses to the bank's specific questions.
• On-Site Audits as Primary Mechanism. Some banks may seek the right to conduct on-site audits at Skybridge's offices or at Osprey Cloud data centers as the primary audit mechanism, rather than relying on the SOC 2 report. The template permits on-site audits but positions the SOC 2 report as the primary audit mechanism. This is operationally important: Skybridge has a 187-person headcount and limited capacity to host multiple simultaneous bank audits. If each bank client insisted on a separate on-site audit, the cumulative burden on Skybridge's engineering, security, and compliance teams would be substantial. If a bank insists on on-site audit as the primary mechanism, consider adding a coordination provision allowing Skybridge to combine audit visits from multiple bank clients (a "pooled audit" approach), which is an accepted market practice for technology service providers serving multiple banking clients.
• Third-Party Auditor Qualifications. Some banks may request the right to designate a specific third-party auditor (e.g., their own internal audit firm or external audit firm) to conduct the audit. This is generally acceptable, subject to the auditor's agreement to Skybridge's standard confidentiality and access protocols. However, if the bank proposes using a competitor of Skybridge's or an auditor with a known conflict of interest, Skybridge should reserve the right to object on reasonable grounds.
F. Schedule A — Description of Processing (Customer-Specific Content)
Schedule A describes the processing activities that Skybridge performs on behalf of the Controller and is a required element of the DPA under Article 28(3) of the GDPR. The following elements of Schedule A must be adapted for each new bank client:
Data Subjects:
Adapt the description of data subjects to reflect each bank client's specific accountholder base. The Meridian DPA identifies data subjects as "accountholders of Meridian Federal Savings Bank, including approximately 412,000 individual accountholders, of whom approximately 3,200 are EU-resident individuals." For each new bank client, obtain the estimated number of accountholders and, critically, the number (if any) of EU-resident accountholders, as this determines whether the GDPR and SCCs are applicable.
Categories of Personal Data:
The core categories of personal data processed through SBF Core are as follows and should generally remain standard:
• Full legal name
• Date of birth
• Social Security Number ("SSN") / Taxpayer Identification Number ("TIN")
• Bank account numbers and routing numbers
• Transaction amounts, dates, times, and metadata
• IP addresses
• Device identifiers
• Geolocation data
• Email addresses
• Phone numbers
• Behavioral biometric data (keystroke dynamics, mouse movement patterns)