Climate Credit Analytical SOW_Final_10Sep24.docx

DOCX document 37 KB Posted

Attached to
Climate Credit Analytical Tool
Solicitation number
2031JW25N00005
Issued by

About this file

This document is a Statement of Work (SOW) for a climate credit analytical tool required by the Office of the Comptroller of the Currency (OCC), Federal Deposit Insurance Corporation (FDIC), and the Federal Reserve. The OCC requires user licenses to a climate credit risk analytical tool that integrates climate-related transition risks into credit and financial risks at the obligor-level. The tool must be compatible with multiple climate scenarios, project financial impacts, and export analytical results. The contractor must provide training and technical support, and the tool must meet accessibility and security requirements. This SOW is related to a pre-solicitation for the "Climate Credit Analytical Tool" with Solicitation Number 2031JW25N00005, issued by the Department of the Treasury's Office of the Comptroller of the Currency.

View the file

Other files

File Type Posted
SSS_Credit Climate Analytical Tool.docx DOCX document

On GovTribe

Work with this file

  • Download the original file
  • Contacts named in this file
  • Similar government files
  • Ask GovTribe AI about this file

Text version

STATEMENT OF WORK

CLIMATE CREDIT ANALYTICAL TOOL

BACKGROUND

The Office of the Comptroller of the Currency (OCC), Federal Deposit Insurance Corporation (FDIC), and the Federal Reserve jointly finalized principles that provide a high-level framework for the safe and sound management of exposures to climate-related financial risks for large financial institutions, which was issued as OCC Bulletin 2023-33 on October 24, 2023 (https://www.occ.gov/news-issuances/bulletins/2023/bulletin-2023-33.html). To measure and monitor banks’ exposures to climate-related transition risks as well as examine climate-related financial risk transmission channels, the OCC requires a climate credit analytical tool to translate transition risk drivers, such as carbon price and other outputs from Integrated Assessment Models (IAMs), to financial impacts at the obligor-level.

SCOPE

The OCC’s Office of Climate Risk (OCR) requires user licenses to a climate credit risk analytical tool that integrates climate-related transition risks into credit and financial risks at the obligor-level.

TRAINING & TECHNICAL SUPPORT

Training:

The Contractor must provide training to help OCC users learn how to use the tool and understand the underlying data and methodology. The Contractor must act upon training requests within at least two business days. Training of new users may be required up to four times per year. Travel to the OCC is not necessary, and the medium of training will be mutually agreed upon between the Contracting Officer’s Representative (COR) and the Contractor. In any case, travel reimbursement is not authorized.

Technical Support:

The Contractor must provide technical support and analytical expertise in the areas covered by the analytical tool, at no additional cost to OCC. The Contractor’s technical support must include telephone or electronic access to the Contractor’s user helpdesk, access to the Contractor’s staff analysts to ask questions or obtain clarifications via e-mail or phone on how to use the Contractor’s analytical tool and understand the underlying data and methodologies. The Contractor must act upon requests and/or inquiries within at least two business days.

PRODUCTS

The Contractor’s tool must meet the following requirements:

· Because the OCC needs this tool largely for bank supervision purposes (e.g., to understand how banks measure and monitor transition risks), the tool must be used by at least two major large US banks (with total assets larger than $250 billion) for modeling climate-related transition risks.

· There are three integrated assessment models (IAMs) commonly used to generate transition risk scenarios (i.e., GCAM, MESSAGE, and REMIND); the tool must have the capacity to use scenario inputs from all three IAMs.

· The tool must be compatible with multiple common climate scenarios, such as Network for Greening the Financial Systems (NGFS) and regulatory climate scenario variables (e.g., ECB, FRB, MAS), and allow user-customized scenarios.

· The tool must include detailed documentation on methodologies behind the estimates, allowing OCC users to understand the workings of the model and underlying sensitivities, to also include performance testing and other validation. The documentation must be updated concurrently with model updates.

· To measure the impact of transition risks on obligor-level cash flows and ratings, the tool must project key items from income statements, balance sheets, and cash flow statements.

· The tool must not require additional purchases of financial data and rating products.

· The tool must export analytical results (for example, to Microsoft Excel and PDF format), and the OCC must be allowed to use the results for internal reporting and analysis.

· Ability to use the tool for research that may lead to journal publications and/or conference presentations.

· Ability to publish/present insubstantial portions of the results from the tool (e.g., summary statistics) in internal and public forums.

· Upon termination, presentations/papers that have been published and/or submitted to conferences, publishers, etc. can remain in the public domain so long as the process was started during the term.

· Any 3rd party data within the acquired tool subject to 3rd party license restrictions as well as any restrictions associated with the data shall be explicitly identified. If not explicitly identified, the requirements of the executed contract shall apply.

IT ACCESSIBILITYSection 508

Section 508 of the Rehabilitation Act, as amended by the Workforce Investment Act of 1998 (P.L. 105-220) requires that when Federal agencies develop, procure, maintain, or use information and communication technology (ICT), it shall be accessible to people with disabilities. Federal employees and members of the public who have disabilities must have access to, and use of, information and data that is comparable to people without disabilities. As such, the following requirements apply to this solicitation:

1) Products, platforms and services delivered as part of this work statement that are ICT, or contain ICT, must conform to the Revised 508 Standards, which are located at 36 C.F.R. § 1194.1 & Apps. A, C & D, and available at https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/final-rule/text-of-the-standards-and-guidelines.

2) E102 / 702.10 – Web Content Accessibility Guidelines (WCAG) 2.0 guidelines success criteria level A & AA are incorporated as a requirement. The referenced WCAG criteria is available at http://www.w3.org/TR/WCAG20/.

3) A completed Accessibility Conformance Report (ACR) found at https://www.itic.org/policy/accessibility/vpat, using Voluntary Product Accessibility Template (VPAT) Revised Section 508 Edition, Version 2.5, is required to assist the Government in determining that the ICT products or services support Section 508 accessibility standards.

4) E202 – General Exceptions Authorized by OCC as applicable.

The following items are identified as containing ICT:

Modify this section as appropriate for the SOW:

· Information, Documentation, and Support

· Hardware

Applicable Functional Performance Criteria: All functional performance criteria apply when using an alternative design or technology that achieves substantially equivalent or greater accessibility and usability by individuals with disabilities than would be provided by conformance to one or more of the requirements in Chapters 4-6 of the Revised 508 Standards, or when Chapters 4-6 do not address one or more functions of ICT.

Applicable requirements for electronic documents and/or support services:

· E205 – WCAG Level A & AA Success Criteria

· E302 – Functional Performance Criteria

· E602 – Support Documentation

· E603 – Support Services

Applicable requirements for hardware*

· 402 – Closed Functionality

· 403 – Biometrics

· 404 – Preservation of Information Provided for Accessibility

· 405 – Privacy

· 406 – Standard Connections

· 407 – Operable Parts

· 408 – Display Screens

· 409 – Status Indicators

· 410 – Color Coding

· 411 – Audible Signals

· 412 – ICT with Two-Way Voice Communication

· 413 – Closed Caption Processing Technologies

· 414 – Audio Description Processing Technologies

· 415 – User Controls for Captions and Audio Descriptions

SECURITY AND PRIVACY REQUIREMENTS

A. General Requirements

Location. Information collected, used, stored, maintained, or otherwise processed by the contractor in the performance of this contract shall be accessed, transferred, stored or processed only within the United States. In addition, the maintenance and support operations of the contractor's technology and information must take place, and originate from, within the United States.

Authorization to Use, Store, or Share Sensitive Information. The contractor shall be responsible for properly protecting all information used, gathered, or developed as a result of work under this contract. The contractor shall also protect all government data, equipment, etc. by treating the information as sensitive. All information gathered or created under this contract shall be considered as Controlled but Unclassified (CUI) information. It is anticipated that this information will be gathered, created, and stored within the primary work location. If contractor personnel must remove any information from the primary work area, they shall protect it to the same extent they would their proprietary data and/or company trade secrets.

Confidentiality. The contractor agrees to assume responsibility for protecting the confidentiality of government records and data associated with this contract, which are not public information.

Deliverables. The deliverables in this contract will be considered CUI and shall not be shared with any other organization without prior written approval from the contracting officer.

B. Configuration Management

System Documentation. System documentation helps personnel understand the implementation and operation of IT components and systems. The contractor shall provide the following technical documentation for IT components covered under this contract to the OCC as directed per the "Security and Privacy Vendor Deliverables" section:

• Administrator documentation that describes secure configuration, installation, and operation of the system, component, or service; effective use and maintenance of security and privacy functions and mechanisms; and known vulnerabilities regarding configuration and use of administrative or privileged functions.

C. Continuous Monitoring

Compliance Reviews and Audits. The contractor shall permit and support compliance reviews and audits under applicable laws to allow the OCC to meet legal and compliance obligations and shall implement processes that allow visibility into the privacy and security controls employed and their effectiveness. The contractor shall provide the OCC or authorized designated officials with information requested by auditors in a timely manner, consistent with the respective auditor's deadline, in support of security compliance reviews and various annual audits, e.g., FISMA, Financial Statement Audit, A-123, etc.

D. Data Protection

Data Encryption. Where encryption is required, as specified by the OCC, the contractor shall ensure that encryption is established and maintained for data at rest and in transit for the duration of the contract. The encryption employed shall be equivalent to those approved in Federal Information Processing Standards (FIPS) Publication 140-2 or 140-3.

Need to Know. Sensitive information, data, and/or equipment will only be disclosed to authorized personnel on a Need-To-Know basis. The contractor shall ensure that appropriate administrative, technical, and physical safeguards are established to ensure the security and confidentiality of this information, data, and/or equipment is properly protected.

General Use of Controlled Unclassified Information (CUI). The contractor shall not use any CUI or CUI subcategories, including, Personally Identifiable Information (PII) or low-sensitivity PII (e.g., E-mail Groups and Lists), for any purpose other than those activities necessary to the performance of this contract.

Use of Contractor Equipment. Use of contractor-owned laptops or other equipment (e.g., media storage devices, servers, etc.) to process, transmit, or store OCC information or to access the OCC network or other OCC information resources without OCC's formal approval is prohibited. This restriction does not apply to the use of non-OCC laptops or PCs to use OCC-approved virtual desktop infrastructure to remotely access the OCC network.

E. Incident Response

Notification. The contractor must report all information security incidents that potentially or actually cause the compromise of OCC information, even if the contractor believes the security incident may be limited, small, or insignificant with respect to OCC data or systems. The OCC will determine when the contractor's reported security incident requires additional focus and attention.

Within one hour from the time the contractor validates that an information security incident has occurred, the contractor must report the security incident information to the OCC Cyber Defense Center (CDC): Computer.Security@occ.treas.gov, (202) 649-7930, regardless of day or time.

The contractor must provide any supplementary information or reports related to a previously reported incident directly to the OCC CDC with the following text in the subject line of the email: “Supplementary Information/Report related to previously reported incident # [insert number].”

Do NOT include any Sensitive Information in the subject or body of any e-mail. To transmit Sensitive Information, use FIPS 140-2 compliant encryption methods to protect Sensitive Information in attachments to email. Passwords must not be communicated in the same email as the attachment.

When notifying the OCC CDC, copy the Contracting Officer if possible or, if reporting by phone or Contracting Officer's email is not immediately available, contact the Contracting Officer immediately after reporting the incident to the OCC CDC.

Information, System and Tool Availability. The contractor shall make available any information, systems and tools necessary for the OCC to respond to incidents in a manner consistent with NIST SP 800-61, as amended. In the case of a reported security incident, the contractor shall provide the OCC with access to the contractor's system and/or facilities within 72 hours of the OCC's request.

F. Information Ownership

Government Access. The government will retain unrestricted rights to government data. The OCC retains ownership of any user created/loaded data and deliverables (e.g., documents, applications, custom code, diagrams, workflows, data sets, etc.) hosted on contractor's equipment, systems, infrastructure, etc., as well as maintains the right to request full copies of these at any time.

Removal of OCC Data. The contractor acknowledges the OCC's exclusive right of ownership of the information and is required to transfer, return, and/or delete all agency data collected, processed, stored or maintained by the contractor on behalf of OCC upon termination of services, and shall provide written certification and supporting documentation attesting to the transfer, return and/or deletion of agency information or data generated, collected, processed, maintained, or stored by the contractor and any subcontractors, per instructions the "Security and Privacy Vendor Deliverables" section.

Documents and Deliverables. The preliminary and final OCC-specific deliverables and all associated working papers are the property of the U.S. Government. The contractor shall not release any information without the written consent of the Contracting Officer. All work papers, preliminary and final deliverables must be submitted to the COR at the conclusion of the contract in an acceptable and usable format, which may include the original format.

eDiscovery. The contractor must ensure data preservation requirements (i.e., halt destruction and maintain data the contractor may not otherwise have to maintain) related to litigation holds are met. The contractor shall also ensure that metadata associated with litigation holds are preserved. Metadata is electronically-stored information that describes the history, tracking, or management of an electronic document. It is created automatically when a user creates, modifies, accesses, or takes other actions with respect to an electronic document.

The contractor shall provide immediate access to all government data and government-related data impacting government data for review or scan, or conduct of a forensic evaluation, and physical access to any contractor facility with government data.

G. System Access

Government Right to Terminate Access. The OCC, at its discretion, may suspend or terminate the access to any systems and/or facilities when an information security incident or other electronic access violation, use or misuse issue gives cause for such action. The suspension or termination may last until such time as OCC determines that the situation has been corrected or no longer exists.

H. Supply Chain Risk Management

Background. In accordance with Federal requirements, the OCC requires supply chain entities to implement necessary security safeguards to: (i) reduce the likelihood of unauthorized modifications at each stage in the supply chain; and (ii) protect information systems and information system components, prior to taking delivery of such systems/components. This control also applies to information system services.

Supply Chain Safeguards. The contractor must:

a. Implement security and privacy controls for systems, facilities, and external connections to systems as necessary to ensure compliance with the laws, regulations, standards, and requirements specified in Sections C. Security and Privacy Authorization, F. Data Protection, and I. System Access.

b. Implement personnel screening processes to ensure suitability in accordance with relevant standards and requirements.

c. Use of tamper-evident packaging during shipping/warehousing.

d. Avoid the purchase of custom configurations to reduce the risk of acquiring information systems, components, or products that have been corrupted via supply chain actions targeted at specific organizations.

e. Vet the processes and security practices of subordinate suppliers, critical information system components, and services.

f. Employ a diverse set of suppliers to limit the potential harm from any given supplier in the supply chain.

g. Implement contract language regarding the prohibition of tainted or counterfeit components.

h. Restrict purchases from specific suppliers or countries per requirements issued by the U.S. Department of Homeland Security (DHS) and/or Federal Acquisition Security Council, as these requirements pertain to the management of supply chain risk for Federal Agencies.

i. Use trusted/controlled distribution, delivery and warehousing options to reduce supply chain risk.

File details come from the government source that posted it. Updated .