Since the development of the RCM, including its second edition in 2019, the notion of the “document” evolved beyond the traditional paper-based written, signed, stamped representation of a filled standardized template, and even beyond the equivalent electronic document in the form of PDF with electronic signature.
It can be considered that any form of structured data representation, that has the ensured proof of origin (authenticity) and an ensured proof of non-tampering, or a clear auditable record of its modifications by authorized identifiable entities only, and that can be rendered in a controlled manner based on standardized templates by authorized systems, can be subject of recognition as a compliant document as long as the applicable regulations accept it.
Thus, along with the physical form of the export certificate or the authenticated electronic reproduction of a physical form, the storage of primary data attributes of the Export Certificate should allow operations assisted by software, such as searching, filtering, investigations, and comparative analysis.
The standardized electronic representation of the Export Certificate should allow the re-generation of a printable certificate document in the form required and in any language required, thus conforming to the specification of the RCM that “Each ICGLR Certificate shall be printed in both English and French. Additional languages may be added at the discretion of the Member State”.
It should be noted that the semantic definition of the certificate fields (data attributes) and their technical representation should not be considered only for the purpose of storage and simple retrieval by ID, but should allow more complex queries that would support traceability, audit and identification of possible problems.
| Cardinality | Technical term | Business term | Description | Usage note | Semantic data type |
|---|---|---|---|---|---|
| 1..1 | issuingCountry | Issuing country | The ISO 3166-1 alpha-2 code of the issuing country | ISO 3166-1 alpha-2 — two-letter country codes | Identifier |
| 1..1 | identifier | Serial number | A unique serial number identifying the Certificate | A unique combination of digits and letters from the standard Latin alphabet, unique in the country, starting with the ISO 3166-1 alpha-2 country code (e.g., RW2324A2) | Identifier |
| 1..1 | exporter | Exporter | A group of business terms providing information about the Exporter. Includes: The name, legal address and physical address of the exporter, as well as any other information required to identify the exporter. | MD.04 Business Entity | |
| 1..1 | importer | Importer | The name, legal address and physical address of the importer, as well as any other information required to identify the importer. | MD.04 Business Entity | |
| 1..1 | lotNumber | Lot number | The exporter’s unique lot number or export order number for the lot | Identifier | |
| 0..1 | designatedMineralDescription | Designated mineral description | A description of the Designated Mineral, including the type of ore or concentrate, weight and grade of the lot | Free textual description | String |
| 1..1 | typeOfOre | Type of ore | Type of ore | MDC.03 Mineral | |
| 1..1 | lotWeight | Lot Weight | Lot Weight | Numeric format, accepting fractional value, should always be read together with the Lot Weight Unit of Measure | Decimal |
| 1..1 | lotWeightUOM | Lot Weight Unit of Measure | The unit of measure used by the lot weight | The unit of measure shall be chosen from the lists in UN/ECE Recommendation N°. 20 “Codes for Units of Measure Used in International Trade”. Can take value from a strict list of UOMs. | MDC.07 Unit of Measurement |
| 1..1 | lotGrade | Lot Grade | Lot Grade | Grade expression might vary depending on the mineral | String |
| 1..1 | mineralOrigin | Mineral origin | The national origin of the material (either the name of the country, or “mixed” in the case of lots containing material from two or more nations mixed together) | One or more country identifiers, separated by one semicolon character (e.g., CD;BI;RW). In case the origin is not known, the character zero (0) will be used. Zero can be combined in an array (e.g., BI;TZ;0). | Identifier |
| 1..1 | customsValue | Customs value | The declared Customs value in USD of the Lot (explicit requirement according to Appendix C of RCM Manual) | Use Currency code of 3 letters (ISO 4217) and value Decimal format, separated by one space character. Alternatively, it can be Decimal considering that it should always be given in USD. | String |
| 1..1 | dateOfShipment | Date of shipment | The date the lot is planned to be shipped | As the export certificate is issued before the shipment occurs, the actual date of shipment might be different. The RCM mandates that the term should be indicated as “Date of shipment”. | Date |
| 0..1 | shipmentRoute | Shipment route | The shipment route | ISO 3166 alpha-2 (array of countries separated by a semicolon without spaces, e.g., CD;TZ;BI) | String |
| 0..1 | transportCompany | Transport company | The transport company responsible for transporting the shipment, if known | String | |
| 1..1 | memberStateIssuingAuthority | Member State Issuing Authority | String | ||
| 1..1 | nameOfVerifier | Name of verifier | Name of the Member State representative responsible for verifying the documentation associated with the export and recommending the issuance of an ICGLR Regional Certificate | String | |
| 1..1 | positionOfVerifier | Position of verifier | Position of the Member State representative responsible for verifying the documentation associated with the export and recommending the issuance of an ICGLR Regional Certificate | String | |
| 0..1 | idOfVerifier | ID of verifier | Identification number (where available) of the Member State representative responsible for verifying the documentation associated with the export and recommending the issuance of an ICGLR Regional Certificate | Identifier | |
| 1..1 | dateOfVerification | Date of verification | The date the lot is verified by the Member State representative | Date | |
| 1..1 | nameOfValidator | Name of validator | The name of the Member State representative empowered to countersign the Certificate to render it valid | String | |
| 1..1 | dateOfIssuance | Date of issuance | The date that the Certificate is countersigned (Certificate is valid from this date) | Date | |
| 1..1 | dateOfExpiration | Date of expiration | The date that the Certificate expires, or the validity period of the Certificate | Between date of issuance and date of expiration should not be more than 90 days | Date |
| 1..1 | certificateFile | Certificate file | The certificate as file | Should take value from a limited list of MIME types: application/pdf, image/png, image/jpeg | File |
Validation Rules
- Lot Weight should be a positive number (>0) with a maximum of 3 decimals (0.000)
- Mineral Origin should have only one of the following formats:
- 2-letters country code (e.g.,
BI) - Array of 2-letters country codes (e.g.,
BI;TZ;CD) - The character zero (
0) in case of unknown origin. Zero can be combined in an array (e.g.,BI;TZ;0) showing that the mineral comes from at least 3 sources, from which 2 are known.
- 2-letters country code (e.g.,
- Date of expiration should not exceed the date of issuance plus 90 days
- Certificate File MIME type should be included in the subset: application/pdf, image/png, image/jpeg
In practical technical implementation, the size of the uploaded files should be limited in order to avoid overloading the storage and processing systems. The limitation should be set at least for the Regional Minerals Database (recommended max size 10 MB), which can be made more strict (e.g., 5 MB, 8 MB) by member states.
Notes on specific attributes
Designated mineral description split: The requirement of the RCM to include “A description of the Designated Mineral, including the type of ore or concentrate, weight and grade of the lot” is proposed to be split into 4 fields: Designated mineral description (textual), Type of ore (mineral, coded based on HS Codes), Lot Weight (in tonnes), and Lot Grade (specific to mineral). It is important that “type of ore” is considered as a separate attribute and is encoded in a standardized manner, ensuring the possibility to query a collection of certificates with interrogations including the mineral.
Mineral Origin encoding: The use of the word “mixed” as proposed in the RCM is replaced with a pattern combining the country codes (based on ISO 3166) with a separator. Separators to be definitely avoided are commas, the percent (%) sign, and the ampersand (&) sign, which have specific interpretations when processed for rendering through HTML on a browser. The proposed encoding uses semicolon as separator.
Date of expiration: It is safer to store the expiry date in clear in the standard Date format rather than computing it from a “validity period” field, to avoid margin of error in calendar calculation. The RCM mandates the expiry date shall be no more than 90 days after the date of issuance.
Shipment route: The RCM requirement for “The shipment route and the transport company” is proposed to be separated into two fields. The Shipment route is represented in a codified form using ISO 3166 alpha-2 country codes, enabling actual querying and traceability auditing. The Transport company remains as String.
Certificate file: This field is added for compatibility with the requirement of RCM to have a traditional document. In the future, this can be replaced by an actual technical record with proof of origin and proof of non-tampering, potentially including a qualified electronic signature or an electronic seal.
