Prepare
Versioned record tables
Every record type is a table with its own owner, in specification order. Files append or start a new version, and column count, order and encoding are checked on the way in.
COCREE 2.0 reporting with record-level validation built in
COCREE 2.0, the BSP’s Enhanced Comprehensive Credit and Equity Exposures Report, asks for borrower- and counterparty-level records on every credit and equity exposure. The BSP checks every file but provides no validation tool, so the bank has to catch errors first. Wekalp’s COCREE package does that, from versioned record tables and BSP code mapping to the filed, encrypted file, for universal, commercial, rural and cooperative banks.
12 record typesHeader and footer, subjects and links, six contract types and negative events.
Every required formatXML or TXT, for the schema your type of institution files.
No BSP validation toolThe BSP returns an exception report after submission and expects banks to check first.
The report
What the BSP’s COCREE 2.0 report asks for
A COCREE 2.0 filing is a set of record files, not a template of totals. Each record type has its own fields, codes and rules, and the counts in the header and footer have to agree with the records themselves.
Filing
A header and footer declare the provider, the period and the expected counts of subjects, contracts and negative events.
Subjects
Every borrower, co-borrower, guarantor or surety, and the links between them, such as directors, owners and parents.
Exposures
Six contract types, from instalment loans and credit cards to investments and off-balance-sheet items, each with role, phase and status.
Negative events
Litigation, bankruptcy and similar events, recorded against each subject.
| What the BSP expects | How Wekalp’s COCREE package handles it |
|---|---|
| Record-level data on every borrower, counterparty and exposure | A versioned table for each record type, with its own owner, loaded from your core banking and loan systems |
| Values from the BSP’s code lists, not your internal codes | Core-system codes mapped once to the BSP’s lists and reused every period |
| Clean files, with no BSP validation tool to check them first | Field, cross-record and file-level checks run before the file is generated, with the regulator’s own error codes |
| Errors corrected and resubmitted | Corrections opened from the BSP’s response file and tracked against the original filing |
| Totals certified by authorised signatories | Maker-checker approval for each table, with control totals computed from the approved records |
| Secure, correctly named submission files | Files generated, encrypted and named to the BSP’s specification |
Submission requirements vary by type of institution. File format, schema and reporting timelines differ for universal and commercial banks, thrift banks, digital banks, rural and cooperative banks and other covered institutions. Wekalp’s COCREE package supports the formats each one files, in XML or TXT, and is offered to rural and cooperative banks as well as universal and commercial banks.
How it works
Source-to-Report AutomationBuild the COCREE records from core banking and loan systems, with codes mapped to the BSP’s lists
Granular readiness · 2-minute self-checkIs your data foundation ready for record-level reporting?
From core-system codes to an accepted COCREE file
COCREE 2.0 expects values from the Data Dictionary’s List of Domains, such as product, location, country and currency codes, not the codes your systems use. The package maps them, keeps every record table versioned, and runs the structural and business checks before the file is generated, so the BSP’s exception report has nothing to send back.
Validate
Field-level validation engine
Rules for presence, format and domain; conditional and cross-field; across records and prior filings; and file totals. Failures carry the regulator’s own error codes and open the records behind them.
File
Filing and regulator response
Files generate only when every table is approved, with control totals computed from the records. Response files load back to accept the filing or open corrections.
The differentiator
A COCREE 2.0 validation engine that speaks BSP
The BSP’s Data Dictionary defines every COCREE 2.0 field: its format and length, whether it is mandatory, the code list it must match, and how it depends on other fields and on the header. Wekalp runs those rules as the regulator writes them, before the file is generated.
702 fields, 442 regulator codesEvery field carries its rules; 664 fields report failures with the regulator’s own error code.
Four rule levelsPresence, format and domain; conditional and cross-field; cross-record and against prior filings; file-level totals and packaging.
Records, not just rulesEach failed rule opens the impacted records with the file they came from, and the cascade a fix will clear.
Re-run and exportUploads after a run mark results stale; re-run per table or for the whole submission; export to CSV.
Controls and evidence
Every COCREE 2.0 filing, approved and on record
The Control Prooflist asks authorised signatories to certify the records and amounts you send. The platform gives them the evidence: approvals per record table, control totals computed from the approved records, and a history of every filing and correction.
Track
Filing history across every package
Every submission to the BSP, for FRP, COCREE 2.0 and the other packages, with its approvals, remarks, validation results and the file that was sent.
Audit
An append-only audit log
Logins, validations, patches, approvals, rejections and filings, each time-stamped against the user and the object, for examiners and internal audit.
Approve
Maker-checker per record table
Each table is approved before the file can be generated. A rejection needs a comment, so the preparer knows what to fix.
FAQ
COCREE 2.0 reporting, answered
What is COCREE 2.0?
COCREE 2.0 is the BSP’s Enhanced Comprehensive Credit and Equity Exposures Report, introduced under Circular No. 1184. It enhances the original COCREE under Circular No. 1131 and asks for borrower- and counterparty-level records on every credit and equity exposure, so the BSP can monitor credit risk across the financial system.
Does the COCREE 2.0 file format differ by type of bank?
Yes. Submission requirements, including file format and schema, vary by type of institution, and some institutions can file in XML or TXT. Wekalp’s COCREE package generates the format your institution files.
Does the BSP provide a COCREE validation tool?
No. The BSP returns a validation (exception) report through the BRMS COCREE 2.0 module after submission, but does not provide a validation program. Banks are expected to adopt their own tools. Wekalp’s validation engine runs the checks before you file.
How are COCREE 2.0 corrections submitted?
Corrected records are resubmitted to the BSP and replace the earlier ones. Wekalp opens corrections from the BSP’s response file, so the team fixes the affected records and tracks each correction against the original filing.
Is Wekalp’s COCREE package available to rural and cooperative banks?
Yes. The package is offered to rural and cooperative banks as well as universal and commercial banks, in XML or TXT. It can run on-premises, in your own cloud account so data never leaves the bank, or in Wekalp’s hosted cloud.