OCC DFAST-14A (annually)

2025 OCC DFAST Data Submission

OCC DFAST-14A Technical Submission Instructions

Contents

1. DFAST-14A Data Submission 2

   1. Overview 2

   2. File Format 2

   3. File Header / Excel Cover Sheet 2

   4. Primary Keys 3

   5. Data Elements 4

   6. Submission 5

   7. File Name 5

   8. Common File Load Issues 6

   9. Version Conventions 7

   10. Submission Date 7

2. DFAST-14A Edit Documentation 7

Appendix A: XML Validation 8

1. Excel XML Validation 8

2. XML File Creation 9

3. Example: Multiple Table XML 9

Appendix B: BankNet Large File Transfer for Templates and Supporting Documentation 13

1. DFAST-14A Data Submission

   1. Overview

This section outlines the technical instructions for submitting the DFAST-14A reporting form. Submissions that do not comply with the technical instructions outlined below cannot be loaded into the system and will require resubmission.

2. File Format

Summary, Operational Risk, Regulatory Capital Instruments and Scenario Schedules Respondents must submit the DFAST-14A summary schedule, operational risk schedule, regulatory capital instruments schedule and scenario schedule in Extensible Markup Language (XML). Extensible Markup Language (XML) is a markup language that defines a set of rules for encoding documents in a common format that can be shared in a consistent way.

An accompanying XML Schema Definition (XSD) describes the elements of XML submission. An XSD describes a set of rules to which an XML document must conform in order to be considered valid according to that schema. XSD describes the structure of an XML document.

The Master XSDs for the above schedules provided should be used for all submissions. Master XSDs contain all data collection items for a given schedule, including ended items. Institutions should use these XSDs going forward for all submissions. Institutions should only populate the data items that are applicable for the report form instructions from the as-of date. Any non-applicable items for a specific as-of date should be omitted from the XML submission.

In general, the XSD items are defined in string format to allow for data types beyond those defined in the data dictionary. This is done to prevent restricting data types in the submission process.

However, certain fields have restrictions set within the XSD; please refer to the schema files for more details. The data submitted should still comply with the data formats provided in the data dictionaries that are distributed with the technical instructions. Any data elements that do not comply with the Field Type and Attributes may need to be revised.

3. File Header

For DFAST-14A XML schedules, XML file headers must include DATA_ASOF_TSTMP while LAST_ASOF_TSTMP is optional. Please see Appendix B: XML Validation for additional information.

¹ https://www.occ.gov/publications-and-resources/forms/dodd-frank-act-stress-test/index-dodd-frank-act-stress- test.html

4. Primary Keys

Primary keys are required to distinguish records as unique. Primary keys can be determined for each schedule by referring to the data dictionary. Primary keys are non-nullable fields and must be completed.

Summary, Operational Risk, Regulatory Capital Instruments and Scenario Schedules.: If an institution does not have data to report on a specified table, these items should be left out of the submission rather than reporting “N/A” for primary keys. In the data dictionary, these fields are determined with “Yes” values in the “Primary Key” column. The data dictionary lists the format the primary keys must be in for files to successfully load. Common primary keys across schedules include the following.

• ID_RSSD

• D_DT

• TRANSTYPE

ID_RSSD must be the unique identifying number assigned by the Federal Reserve.

D_DT and DATA_ASOF_TSTMP must be provided in "Date_Time” format ‘YYYY-MM-DDThh:mm:ss’, where:

• YYYY represents the year;

• MM represents the month;

• DD represents the last day of the reporting month;

• T represents the start of the required time section;

• hh represents the hour;

• mm represents the minute; and,

• ss represents the second.

For example, the June 2013 reporting period would be represented as ‘2013-06-30T00:00:00’.

TRANSTYPE should always be filled with the value “I”. The OCC only accepts insertions of new data records, we cannot accept updates to existing data records or deletions of existing data records. Should a respondent wish to update an existing data record, the respondent must resubmit the entire completed schedule corresponding to the data record. The OCC only accepts “full” resubmissions; “partial” resubmissions cannot be accepted.

5. Data Elements

Summary, Operational Risk, Regulatory Capital Instruments and Scenario Schedules: DATA_ASOF_TSTMP should be provided in date time format ‘YYYY-MM-DDThh:mm:ss’, which is provided above. (This format also applies to LAST_ASOF_TSTMP, which is an optional attribute.)

Each schedule has an XSD that contains all data elements collected. Respondents can utilize the most recent XSD for current submissions and submit applicable data items per the instructions of the submission date using the DFAST-14A instructions of the respective as-of date.

All scenarios for the summary schedule should be submitted together as one file. The Operational Risk and Regulatory Capital Instruments schedules should be submitted as separate files. The mandatory scenarios for DFAST are Baseline, Severely Adverse, Bank Baseline, and Bank Stress. The bank must submit all mandatory scenarios, even if the bank supplies identical results for the supervisory baseline and bank baseline scenarios. Additional scenarios are optional.

Each scenario and projection period is required for items CCARP006 and CCARP009, respectively. The permissible values for CCARP006 are the following (mandatory items in bold):

• Baseline

• Severely Adverse

• Bank Baseline

• Bank Stress

• Additional Scenario 1

• Additional Scenario 2

The allowable values for the P&L Category (CPSSLD41) in the Summary Schedule is limited to “CVA Hedges” or “Trading”.

The allowable values for the Scenario Name field (CCARP006) in the Operational Risk Schedule are limited to “Bank Baseline” and “Bank Stress”.

For the Regulatory Capital Instruments Schedule, the Submission Type (CACIH346) must be filled with the value “Original”. The OCC does not accept adjusted or incremental regulatory capital instruments schedules.

As respondents fill in data elements, they should adhere to the following guidelines.

• Items applicable to the entire projection horizon, such as those on the Trading and

Counterparty worksheets, should only be populated for PQ1 and the values should be for the entire projection period.

• Items should be reported as 0 instead of 0.000000. If an item is not applicable to your submission the field should be omitted from the XML submission. In addition, the institution should provide a list of all items which are not submitted or for which null or missing values are provided, along with a brief explanation for why the field is not applicable to the institution.

• Report dollar values in millions of U.S. dollars (unless specified otherwise).

• Dates should be entered in an YYYYMMDD format (unless otherwise indicated).

• Report negative numbers with a minus (-) sign.

• Report income and loss data on a quarterly basis and not on a cumulative or year-to-date basis.

6. Submission

The XML file, excel schedules, and all supporting documentation should be uploaded through the BankNet system. Please see Appendix B: BankNet Large File Transfer for Templates and Supporting Documentation.

7. File Name

Summary, Operational Risk, Regulatory Capital Instruments and Scenario Schedules: The file name for all XML data submissions should be formatted as follows.

DFAST14A_(RSSD ID)_(Template_Name)_(Submission Year)_(Version Number*).xml

• “Test” can be used in place of version number to indicate a test file. See the following examples.

Summary Schedule

• DFAST14A_123456_Summary_2025_1.XML

• DFAST14A_123456_Summary_2025_TEST.XML

Regulatory Capital Instruments Schedule

• DFAST14A_123456_RegCapInstruments_2025_1.XML

• DFAST14A_123456_RegCapInstruments_2025_TEST.XML

Operational Risk Schedule

• DFAST14A_123456_OPSRISK_2025_1.XML

• DFAST14A_123456_OPSRISK_2025_TEST.XML

Scenario Schedule

• DFAST14A_123456_Scenario_2025_1.XML

• DFAST14A_123456_Scenario_2025_TEST.XML

Failure to follow this naming convention will cause a file rejection by the BankNet system or will cause the document to be incorrectly processed.

Important clarifications for the file naming convention (these apply to all submitted schedules):

• DFAST14A must be one continuous word. No additional spaces or separating punctuation should be included (i.e. use DFAST14A instead of DFAST-14A, DFAST_14A, etc.)

• The template name in the file name must be one continuous word. Underscores in the template name should not be used (i.e. Use RegCapTransitions instead of RegCap_Transitions).

8. Common File Load Issues

Below is a list of common file load issues. Banks are reminded that they should not manipulate (add/delete rows, add subheaders) the original structure of the Excel templates. Banks that fail to follow this instruction will be required to resubmit.

• Incorrectly formatted record headers.

• Not using the most recent XSD provided.

• Incorrect transtype provided.

• DateTime fields incorrectly formatted.

• Null or missing primary keys.

• Duplicate records with identical primary keys.

• Incorrect ID_RSSD.

• Incorrect D_DT.

• Incorrect filename.

• Manipulation of structure of original excel templates.

• Zipped XML files or excel submissions.

• Failure to submit a cover sheet with each schedule.

9. Version Conventions

All Schedules: The first submission for each 2025DFAST14A schedule is version 1. For example, when a hypothetical respondent with RSSD_ID = “123456” submits the 2025 DFAST Summary schedule for the first time, the name of the file would be the following.

• DFAST14A_123456_Summary_2025_1.XML

If a respondent resubmits a schedule, the version number should be incremented by 1 for each resubmission. For example, if the same hypothetical respondent resubmitted the 2025 DFAST Summary schedule, the name of the file would be the following.

• DFAST14A_123456_Summary_2025_2.XML

Only “full” resubmissions of schedules are permitted, “partial” resubmissions cannot be accepted. A respondent should only provide a full resubmission for the schedule(s) being modified; the respondent should not resubmit all DFAST schedules if only one schedule is being changed.

10. Submission Date

All Schedules: All schedules will be due on or before the end of the submission date, unless that day falls on a weekend, in which case the data must be received on the first business day after the weekend or holiday (subject to timely filing provisions). No other extensions of time for submitting reports will be granted. The submission due date will be April 7, 2025. The data ‘as-of date’ will be quarter end of the most recently filed Call Report available prior to the submission due date.

2. DFAST-14A Edit Documentation

For the DFAST 2025, submission is due on April 7, 2025, the OCC will be running a series of data integrity checks against DFAST-14A reporting template submissions. If errors are identified in an institution’s submission, the OCC will notify the institution and they will be asked to resubmit. Additionally, data integrity checks may highlight items of an institution’s DFAST-14A submission which require further clarification but may not necessarily result in a resubmission.

Below is a general description of the types of data integrity checks to be performed by the OCC. Please note that the list below is not intended to be exhaustive. Institutions are responsible for adhering to all the requirements outlined in the DFAST-14A instructions and for ensuring the integrity and accuracy of their own submissions. The OCC will not be providing a full list of the data integrity checks to institutions in advance of the submission date.

• Institutions should ensure that submitted values correspond to the field types supplied in the Summary, Regulatory Capital Instruments, Operational Risk and Scenario Schedules data dictionaries. Institutions should not supply alphabetic characters for numeric fields.

• Institutions should not supply a numeric value less than zero where a nonnegative value is expected.

• For Primary key fields, please refer to section 1.3 of these instructions.

Appendix A: XML Validation

XML validation is the process of checking a document written in XML to confirm that it is both well-formed and valid. A well-formed document follows the basic syntactic rules of XML, which are the same for all XML documents. A valid document respects the rules dictated by the XSD.

There are various free tools available that will validate XML documents against given XSDs.

• XML Notepad 2007 (http://www.microsoft.com/en-us/download/details.aspx?id=7973) provides a simple intuitive user interface for browsing and editing XML documents.

• Notepad++ (http://notepad-plus-plus.org/) plugin that offers XML validation against an XSD.

• Xerces C++ (http://xerces.apache.org/xerces-c/) is a validating XML parser written in a portable subset of C++. Xerces C++ makes it easy to read and write XML data.

Microsoft Excel offers a built-in function to validate XML data against an XSD to ensure that any XML data you import to or export from one or more cells in a mapped range in a worksheet conforms to the XSD in the XML Source task pane.

1. Excel XML Validation

   1. On the Developer menu, point to XML, and then click XML Map Properties to display.

   2. In the XML Map Properties dialog box, select Validate data against schema for import and export.

Please see the screenshot below for an example of a graphic display of how to validate and export an XML file.

2. XML File Creation

The following examples provide instructions on how to create an XML file that contains multiple tables. The example provided demonstrates how to properly map a DFAST-14A Summary file but it can be replicated to map any of the multiple table files collected in the DFAST-14A schedules.

A. 3. Example: Multiple Table XML

The following process is an example of how an XML file can be created. Details for the reported values and the MDRM’s can be found in the accompanying data dictionary documentation. This documentation will identify the reported value and further prescribe the data type and format that is expected for the reported values. To map an .xsd follow the steps below using the 2025DFAST14A_Summary_Version_1.xsd as an example.

1. Save the DFAST14A_Summary_Version_1.xsd to a local drive that can easily be accessed.

2. Open a new Excel document, select the ‘Developer’ tab in the toolbar at the top, and locate the ‘Source’ icon. Once selected, a pane on the right-most portion of the screen will appear. Select ‘XMLMaps...’ from the bottom of the pane and then select ‘Add…’ from the pop-up screen.

3. Next locate and select the DFAST14A_Summary_Version_1.xsd and click open. The ‘Multiple Roots’ dialog box will appear. Select the SMRY_Data_Collect option and then click ‘OK’.

4. Then select ‘OK’ on the ‘XML Maps’ dialog box. After selecting ‘OK’, the data elements will populate in the right-hand pane. We will map each of the tables to a separate tab. For reference, label nine tabs according to the nine sets of data being collected.

5. First map the DATA_ASOF_TSTMP and LAST_ASOF_TSTMP tags. While pressing the ‘CTRL’ key select those two items with the mouse then click and drag the cursor to cell A1. Cells A1 and B1 will then be highlighted indicating successful mapping of these two items.

We will next map the items collected on each of the tables. The first set of items for the ACT tab will be mapped using the SMRY_Data_Collect_ACT icon in the right-hand pane. Select the SMRY_Data_Collect_ACT which will highlight the corresponding items. Click and drag the heading to cell C1. The image below depicts how this should appear.

6. The second set of items for the PROJ tab will be mapped using the SMRY_Data_Collect_PROJ icon in the right-hand pane. Select the corresponding Excel tab and then select the SMRY_Data_Collect_PROJ which will highlight the corresponding items. Click and drag the heading to cell A1. The image below depicts how this should appear (DATA_ASOF_TSTMP and LAST_ASOF_TSTMP tags do not need to be mapped for this tab).

7. Similarly, the rest of the tabs would be mapped according to the above example. DATA_ASOF_TSTMP and LAST_ASOF_TSTMP tags do not need to be mapped for the rest of the tabs.

8. Now all of the requested items have been mapped. Complete the data fields as prescribed by the information in this document and in accordance with the data dictionary document

provided (note: all data will be completed below the header. For instruction number 5, DATA_ASOF_TSTMP and LAST_ASOF_TSTMP should be input directly into cells A1 and B1. Once all data have been input, export into the desired .XML format that is needed for submission. First select ‘Export’ from the ‘Developer’ tab in the toolbar at the top. Then name file according to the format prescribed in section 1.7 of these technical instructions and select ‘Export’.

Notes:

• Excel changes date formats into Julian Date; to ensure the date is in the correct format listed in the technical instructions all date fields should be formatted as text.

• If a schedule has multiple tables and an institution does not have data for one of the tables do not provide any values for the primary keys.

• These instructions work for the current excel version of Office 2013 as of September 30, 2014. Any software updates to Microsoft could alter these instructions.

Appendix B: BankNet Large File Transfer for Templates and Supporting Documentation

For information on submitting files through BankNet, including information on Registering for BankNet and/or contacting BankNet technical support, please visit the OCC BankNet webpage.

https://www.banknet.gov/entrance/default.html

Please note that when uploading files through BankNet, XML files (Summary Schedule, Operational Risk Schedule, Regulatory Capital Instruments Schedule and Scenario Schedule.) should not be compressed (zipped). Zipped XML files will not be processed. Each XML file must be uploaded individually. For information regarding the correct folder location for Supporting Documentation, please reference Appendix A of the OCC’s DFAST14A Reporting instructions or reach out to dedicated OCC supervisory staff.

1