Operational Resilience

Insurance

As soon as possible, but at least prior to access to the production API key, it is required for the Company to gather fully executed  insurance and to provide a copy of the policy limits via a Certificate of Insurance (COI). We understand that insurance can be expensive and sometimes complicated however, we want to ensure your success is not hindered by the costly expenses of litigation or liability claims.

Engage in discussions with your insurance broker for the following coverages:

• Data security / cyber liability*
• Professional liability / errors and omissions*
• Commercial liability insurance*
• Commercial crime insurance*
• Executive & Officer personal liability (optional)
• General umbrella (optional)
• Workers’ compensation (per state requirements)

*Limits of $1M or greater per occurrence and in aggregate are required.

We recommend reviewing these insurance requirements, along with any additional recommended insurance coverages, to obtain an overall insurance policy that makes the most sense for your company. Vouch, Marsh, and Founder Shield are examples of providers that commonly work with startups.  You are welcome to work with any insurance broker or provider of your choosing, as long as the minimum insurance limits are executed and evidenced via a COI.  Additional information about startup insurance can also be found here.

Business Continuity and Disaster Recovery

As the Company designs and builds its operations, it should have processes and plans that will ensure operational resilience, continuity, and if needed, contingency options. This is reflected in a business continuity plan, disaster recovery plan, and adequate testing. 

Business continuity planning ensures programs and processes are in place for continuing operations during a disruptive event. Disaster recovery planning is concerned with preemptively identifying key systems and recovery plans in the event that a partial or complete destruction of systems occurs. Business continuity planning and disaster recovery planning can help identify gaps and concerns to minimize impacts in the event that a disaster or system failure occurs. The Sponsor Bank may choose to take part in the testing or request a copy of the test results. There may also be service level agreements that the Company adheres to with respect to uptime and recovery time objectives (RTO), per Sponsor Bank requirements.

It is recommended that simulation exercises be performed, across various departments to ensure from a business readiness perspective, all key systems and tools are recoverable and operational, within the expected RTO.  

The Business Continuity Plan should be customized to the Company, its services, environments, and the geographic locations its IT and infrastructure is held. Ready.gov is a strong resource for additional details for what the plan should include. 

A Business Impact Analysis (BIA) will need to be targeted to the individual fintech, its services, environments, and the geographic locations that their IT and infrastructure is held.

The Disaster Recovery and Failover Plan would include details for how to implement and manage a restoration effort in the event of a disaster. This plan will also help address failover capabilities in the event that primary systems and connected APIs fail. If operating on cloud-based active/active service deployments with multiple data centers and high availability modes, these can be mitigating factors for a more streamlined Disaster Recovery and Failover Plan. Also, check your cloud service provider for details about Disaster Recovery Failover from service providers such as Microsoft Azure (Link), AWS (Link or Link) or GCP (Link or Link), for additional details.

Incident Management

An Incident Management (IM) / Incident Response (IR) Plan should include details surrounding the following steps: Preparation, Identification, Containment, Eradication, Recovery and Lessons Learned.  The IM / IR Plan should also document Service-Level Agreements and requirements of notification to your Sponsor Bank and Partners (including, but not limited to Synctera) in the event of suspected data and security breach(es). Incident management will also include proper and timely notification of any incidents that impact the Company’s end customers.

The Sponsor Bank has regulatory requirements to receive from the Company and to report material incidents to its regulator. 

An incident generally involves an event that last for four (4) or more hours such as: 

• A significant computer-security incident that disrupts or degrades, or is reasonably likely to disrupt or degrade, the viability of the operations;
  • Examples of such events include one (1) or more:
    • Major computer-system failure(s); 
    • Cyber-related interruption(s), such as a distributed denial of service or ransomware attack(s); or
    • Significant operational interruption.
• Results in customers being unable to access their deposit and other accounts; 
• Impacts the stability of the financial sector. 

Regardless of the time period, a suspected or confirmed breach of systems including direct or indirect access to client data, must also be reported as an incident to your Sponsor Bank and any impacted Partners (including, but not limited to Synctera), as soon as possible.  

Third Party Risk Management

Sponsor Banks want to understand the Company’s third party relationships and subcontractors, especially those that are critical to its operations (e.g. cloud service providers) or risk and compliance functions (e.g. KYC providers, transactions monitoring tools). 

Prior to being provided access to the production API key, there are three key documents that must be submitted by the Company:

• Third Party Risk Management policy
• Completion of the Third Party List and Risk Rating
• Reports for select third party relationships based on the risk of the third party

Companies are required to establish a Third Party Risk Management program and policy, which includes the process to inform Sponsor Banks of any new material third party relationships as well as to identify, assess, and manage the risks of those relationships. This can include requesting those third parties to provide independent reports such as SOC 2, Type II reports, PCI-DSS or ISO Certifications, and supporting audit packages and materials. Sponsor Banks generally require the Company to provide evidence of the review (e.g., memo, report, and/or working papers), not simply the requested materials. 

Any material third party relationships will need to be reflected in the Third Party List and Risk Rating Form.  This form should be reviewed, completed and shared with Synctera as soon as possible. Any Critical relationships will require a risk review (see Vendor Risk Review Report Template with Instructions) to be performed prior to the Company’s production API key access. Each assessment takes, on average, seven (7) days to complete.  However, several assessments can be performed concurrently.  Note: depending on the services outsourced, you may not have any identified Critical relationships, third party services, or vendors.

Bank regulators have also released finalized guidance on third party relationships that includes basic principles for how Sponsor Banks should monitor their partners’ third parties and subcontractors.  In some cases, regulators may request information on the Company’s third party program through the Sponsor Bank.