Certificate Generation¶

Certificates are auto-generated risk records created from bordereau processing — one per insured item in the spreadsheet. The generation mode and the mapping from bordereau coverage fields to certificate risk fields are both configurable.

Generation mode¶

Where supported, certificate generation mode is controlled via a bordereauRiskGenerationMode setting in the duaConfig block of be_config.json (S3 business config):

{
  "duaConfig": {
    "bordereauRiskGenerationMode": "NEW_VERSION_WITHOUT_MTA"
  }
}

Mode	Behaviour
`NEW_VERSION_WITHOUT_MTA`	When differences are detected between bordereau versions, creates a new version of the certificate risk without generating a full MTA. History is tracked via `RiskDecLink`.
`NEW_VERSION_WITH_MTA`	Creates full MTA risks when differences are detected. Produces more records and more data complexity.

NEW_VERSION_WITHOUT_MTA is generally preferred because it creates a cleaner audit trail and avoids the overhead of MTA processing for what are often minor data corrections.

Note

The base repository's duaConfig block does not include bordereauRiskGenerationMode out of the box — confirm whether the setting is honoured on your active core platform version with your delivery lead before relying on it.

Coverage-to-field mapping¶

Specific coverage codes in the bordereau drive the population of standard fields on the generated Certificate risk. These mappings are fixed by the platform — no configuration is needed to enable them, but the coverage codes must exist in your SOV definition for the mapping to work.

Coverage Code	Maps To
`COV_DUA_EXPIRY_DATE`	`risk.expiryDate` (required for RISK and COMBINED bordereau types)
`COV_DUA_INCEPTION_DATE`	`risk.inceptionDate` (required for RISK and COMBINED)
`COV_DUA_REINSURED_NAME`	`company.name` on `risk.insuredParty`
`COV_DUA_FIRM_ID`	`CompanyIdentifier` of type `INSURED_FIRM_ID` on insured party
`COV_DUA_BINDER_UMR_AGREEMENT_NO`	`risk.umr`
`COV_DUA_RISK_TRANSACTION_TYPE`	`risk.contractType` (must match `contract_type` business constant)
`COV_DUA_COVH_DEC_REF`	`policy.policyReference` (the certificate reference number)
`COV_DUA_LIMIT_OF_INDEMNITY`	`policy.limitOfIndemnity`
`COV_DUA_PREMIUM_AMOUNT`	`premiumTransaction.expectedAmountInOriginalCurrency`
`COV_DUA_CURRENCY`	`premiumTransaction.originalCurrencyCode`

Including coverage codes in SOV¶

For these mappings to work, the relevant COV_DUA_* codes must be defined as coverages in:

business-constants/coverage.json — define each coverage field
The business class JSON under coverages[] — link them to the LOB

When the underwriter maps SOV columns to coverage fields, they map the spreadsheet's inception date column to COV_DUA_INCEPTION_DATE, the insured name column to COV_DUA_REINSURED_NAME, and so on.

Version tracking¶

When NEW_VERSION_WITHOUT_MTA is used, Workbench tracks certificate history via RiskDecLink. Each new bordereau version that changes a certificate creates a new record linked to the original certificate via RiskDecLink, maintaining a full audit trail without the overhead of MTA processing.

Certificate documents¶

Certificates can have their own document templates, configured using the same document generation approach as Open Market risks. The certificate risk has access to:

Standard risk fields (risk.insuredParty, risk.inceptionDate, etc.) — populated from the COV_DUA_* mappings above
Policy fields (policy.policyReference, policy.limitOfIndemnity) — from the bordereau mappings
Parent master risk data — accessible via the masterRisk path in templates

Testing certificate generation¶

Create a Master contract with a completed contract structure
Create a bordereau (INBOUND_BORDEREAU) declaration
Upload a test SOV spreadsheet with all required COV_DUA_* columns
Complete the asset mapping step
Trigger bordereau processing
Verify that certificate risks are created with the correct field values
Generate a certificate document and verify data mappings