Russian Drug Serialization vs EU FMD — DataMatrix 36×36, Crypto Tail and API Integration with CRPT


Registration is complete. The GMP certificate is in hand. The dossier has been approved. One «minor technical detail» remains: launch serialization. Then it turns out that the HQ IT team has never heard of the Russian monitoring system, and the local integrator is quoting six months of implementation time and a budget that rivals the annual profit from Russian sales.
This article is a technical brief for IT directors and development teams. No vendor marketing, no product endorsements. Just the legal requirements, data formats, and the sequence of steps.

Before. EU FMD as the Starting Point

Most foreign manufacturers already operate under EU FMD (Falsified Medicines Directive). The European system requires applying a 2D DataMatrix code to the packaging and transmitting data to national repositories via the European Hub.
The underlying logic is similar: a unique code on every pack, authenticity verification at every stage of the supply chain. Technically, EU FMD is simpler. The code contains the GTIN (Global Trade Item Number), serial number, expiry date, and batch number. There is no cryptographic protection.
f the production line is already configured for EU FMD, adapting it to Russian requirements will mean changes across several components. The code structure will change (a cryptographic «tail» is added), the DataMatrix size will grow (36×36 modules instead of 26×26), and integration must shift from the European Hub to the Russian system.

After. Requirements of FGIS MDLP

The Federal State Information System for Monitoring the Movement of Medicinal Products (FGIS MDLP) has operated in Russia since 1 July 2020. The system operator is the Centre for the Development of Advanced Technologies (CRPT).
Government Resolution of the Russian Federation No. 1556 dated 14.12.2018 establishes the mandatory requirements for the identification means and the procedures for working with the system.

Marking Code Structure

The marking code consists of four data groups. Each group has a fixed structure and length:

GroupApplication Identifier (AI)ContentLength
1(01)GTIN14 digits
2(21)Serial number13 characters
3(91)Verification key4 characters
4(92)Verification code (crypto tail)44 characters

Between groups 2 and 3, and between groups 3 and 4, a GS separator character (ASCII code 29) or the FNC1 control character is used.
Total code length: 83 characters (without separators) or 85 characters (with GS separators).
Structure example:

[FNC1]01[14-digit GTIN]21[13-character serial number][GS]91[4-character key][GS]92[44-character crypto tail]

The serial number is either generated by the manufacturer or requested from the operator. Permitted characters: digits 0–9, Latin letters A–Z and a–z. The serial number is case-sensitive, so «FxlCrA0zNaEol» and «FxlCrA0zNaeol» are treated as different codes.

DataMatrix Technical Specifications

Resolution No. 1556 sets out the following barcode requirements:

ParameterRequirement
FormatData Matrix ECC-200
Dimensions36 × 36 modules
Print quality classC or above per ISO/IEC 15415-2012
Error correction methodECC-200 per GOST R ISO/IEC 16022-2008

The code is applied to the secondary (consumer) packaging. Where secondary packaging is absent, it is applied to the primary packaging. Printing on a label and then applying it is permitted, provided the label cannot be removed without damage.
The information in the code is duplicated in human-readable form: GTIN and serial number are printed in plain text alongside the DataMatrix symbol.

FGIS MDLP Integration Architecture

The system operates across four integration levels:

LevelComponentFunctions
L1Production lineSerialization equipment, DataMatrix code generation and printing, print quality verification
L2Shop-floor systemProduction job management, pack aggregation into transport units, SSCC code generation (Serial Shipping Container Code)
L3ERP/WMSCorporate accounting, serialization data storage, shipping document preparation
L4External systemsAPI integration with FGIS MDLP, XML document exchange under established schemas

Emission Registration Device

Marking codes are not generated at the manufacturing site. They are issued by the FGIS MDLP operator. To obtain codes, the manufacturer uses an Emission Registration Device (ERD) or remote access to one.
CRPT provides the ERD free of charge. The manufacturer signs a contract with CRPT and selects the method of code retrieval:
1. A physical device at the manufacturing site
2. Remote access to the ERD in the operator’s infrastructure (cloud option)

The second option is more practical for foreign manufacturers: no equipment needs to be deployed abroad, and API integration is sufficient.
Code retrieval workflow:
1. The manufacturer submits a request via the ERD (API call)
2. The request specifies the GTIN and the number of codes required (or pre-defined serial numbers)
3. CRPT generates the cryptographic verification codes
4. Codes are returned to the manufacturer within 2 hours of the request
5. The manufacturer applies the codes to the packaging
6. After packaging is complete, an application report is submitted to FGIS MDLP

    Marking Code Payment

    The cost of one code is set by Government Resolution of the Russian Federation No. 577 dated 08.05.2019. As of January 2026, the price is 0.50 RUB (excluding VAT) per code.
    Payment options:
    Prepayment before codes are issued
    Deferred payment within 350 calendar days of the code issuance date, but no later than the product’s entry into circulation

    Data Formats and XML Schemas

    All interaction with FGIS MDLP is conducted through XML documents. Each operation has a designated schema number:

    Schema No.Operation
    10300Marking code emission
    10311Packaging completion in Russia (application report)
    10319Medicinal product release outside Russia (application report)
    331Shipment to Russia (direct procedure)
    332Import to Russia (reverse procedure)
    335Release for domestic consumption
    341Acceptance at warehouse from customs control zone
    342Entry into circulation in Russia
    911Aggregation into transport packaging
    915Multiple aggregation

    XSD schemas are available on the Honest Sign website (chestnyznak.ru) in the MDLP documentation section.

    Aggregation and SSCC Codes

    When forming transport packaging (cartons, pallets), the manufacturer assigns an SSCC code to each unit. It consists of 18 digits and is represented as a linear barcode with Application Identifier (00).
    Aggregation means linking SGTIN codes (Serialized GTIN, the serial identifier of consumer packaging) to the SSCC code of the transport unit. The manufacturer submits aggregation data to FGIS MDLP using schemas 911 or 915.
    Going deeper than two nesting levels (carton and pallet) is not advisable: the hierarchy becomes more complex without any practical benefit.

    What to Do. Step-by-Step Implementation Plan

    Step 1. System Registration (7 days)

    The Marketing Authorisation Holder (MAH) or its Russian representative registers in FGIS MDLP through the operator’s personal account portal.
    Registration requires:
    Electronic signature: qualified e-signature for a Russian representative, simple e-signature for a foreign company
    Information on manufacturing sites
    Product details (marketing authorisation numbers)

    Upon registration, the participant receives a personal account with API access.

    Step 2. Product Registration (concurrent with Step 1)

    Each product is registered in two systems:
    1. GS1 Russia Association (to obtain the GTIN)
    2. FGIS MDLP (to link the GTIN to the marketing authorisation)
    Product registration in MDLP is completed via an electronic application specifying the GTIN and the MA number. The system automatically retrieves data from the Unified Structured Reference Catalogue of Medicinal Products (USRC) maintained by the Ministry of Health.

      Step 3. Contracts with the Operator (14 days)

      The manufacturer signs two agreements with CRPT:
      Contract for the provision of the Emission Registration Device (or remote access to it)
      Contract for marking code payment

      Standard contract templates are approved by the Ministry of Industry and Trade of Russia. A foreign manufacturer may operate through an authorised representative in Russia.

      Step 4. IT Systems Readiness (21 days after registration)

      Within 21 calendar days of registration, the participant must ensure that its information systems are ready to interact with FGIS MDLP.
      Minimum IT system requirements:
      Ability to generate and submit XML documents under the established schemas
      Receipt and processing of responses from FGIS MDLP (acknowledgements)
      Storage of marking code data and associated transaction records
      Generation of code requests via the ERD

      Step 5. Integration Testing (2 months)

      Once IT systems are ready, the manufacturer submits a testing application to the operator. The operator runs the testing on FGIS MDLP’s test environment.
      All operations are verified on the test environment: code request and retrieval, application reports, shipment and import into Russia, aggregation and de-aggregation, error handling, and exception management. Upon completion, the operator issues a confirmation of readiness to work in the production environment.

      Step 6. Production Launch

      After successful testing, the manufacturer begins serializing commercial batches. It is advisable to conduct the first shipments with the involvement of a Russian distributor experienced in MDLP operations.

      Direct and Reverse Import Procedures

      Resolution No. 1556 provides two options for registering imports in FGIS MDLP.

      Direct Procedure (recommended)

      1. The manufacturer (MAH or representative) creates a «Shipment to Russia» document (schema 331) before dispatching the goods
      2. The document specifies the SGTIN or SSCC codes, the importer’s details, and shipping document references
      3. Submission deadline: within 45 working days of the shipment date, but before the goods arrive in Russia
      4. The importer confirms receipt (schema 701) within 5 working days of the delivery date

        Under the direct procedure, the manufacturer controls the entire process and the importer only confirms receipt.

        Reverse Procedure

        The importer creates an «Import to Russia» document (schema 332) after the goods are delivered
        The document specifies SGTIN or SSCC codes based on scanning the received goods
        Submission deadline: within 5 working days of the delivery date or the completion of aggregation
        The manufacturer confirms the shipment (schema 701)

          This procedure applies when the manufacturer does not have the technical capability to work with FGIS MDLP directly.

          Customs Warehouse Serialization

          If serialization is not possible at the overseas manufacturing site, it may be carried out at a bonded customs warehouse in Russia. This applies to imports of finished products where code application at the factory is not feasible.
          Requirements:
          The customs warehouse must be listed in the pharmaceutical activity licence as a place of operations
          Labels with DataMatrix codes are pre-printed and shipped to the warehouse
          Serialization must be completed before the goods are released for domestic consumption

          Document flow:
          The MAH submits a warehouse serialization report (schema 3(1) of Annex 3 to Resolution No. 1556)
          Once serialization is complete, an application report is submitted (schema 10319)
          Standard import procedures follow (schemas 331–342)

          Common Errors and How to Avoid Them

          Incorrect Marking Code Structure

          Frequent issues: the number of characters in a group does not match the specification (GTIN not 14 digits, serial number not 13, key not 4, crypto tail not 44), GS separator characters are missing between groups, Application Identifiers (01), (21), (91), (92) are absent.
          Before going live, test code generation on the MDLP test environment. Set up automatic validation of code length and structure on the production line.

          Print Quality Below Class C

          A DataMatrix with print quality below class C cannot be read by standard scanners. Causes vary: worn print head, unsuitable ink, code size too small, printing on an uneven surface.
          Install an inline print quality verification system. Calibrate printers regularly. Keep the module size at no less than 0.5 mm.

          Case Sensitivity of Serial Numbers

          «FxlCrA0zNaEol» and «FxlCrA0zNaeol» are different codes. If the wrong case is used when submitting the application report, the code will be invalid.
          Store serial numbers exactly as received, without any transformation. Configure scanners to transmit data as-is.

          Late Data Submission

          The application report must be submitted before the product enters circulation. The shipment document must be submitted before the goods arrive in Russia.
          Automate document generation and submission. Integrating FGIS MDLP with the manufacturing execution system is more reliable than manual operations.

          Action Plan for the IT Director

          1. Audit the existing serialization infrastructure. Identify which components can be reused, which require modification, and which need to be built from scratch.
          2. Assemble the project team: API integration developer, production equipment engineer, GS1/GMP specialist, project manager with Russian regulatory knowledge.
          3. Choose the solution architecture. Two options: extending the existing MES/ERP to work with the Russian API, or introducing a middleware layer between the corporate systems and FGIS MDLP.
          4. Allocate a minimum of 2 months for integration testing. Cover all scenarios: normal operations, connectivity failures, system unavailability, and error correction.
          5. Document contingency procedures for system outages. FGIS MDLP permits operation in «emergency mode» with data upload within 3 working days.

            Penalties for Non-Compliance

            Violations of serialization requirements carry administrative liability under Article 6.34 of the Russian Code of Administrative Offences:
            For officials: a fine of RUB 5,000–10,000 with product confiscation
            For legal entities: a fine of RUB 50,000–100,000 with product confiscation

            Late or inaccurate data submissions to MDLP carry equivalent fines without confiscation (Articles 15.12.1–15.12.2 of the Code of Administrative Offences). Since 1 March 2025, selling medicinal products where MDLP holds no marking code record, or where serialization requirements have been violated, is prohibited.
            Russia’s serialization system is technically more demanding than EU FMD — a larger DataMatrix, a cryptographic verification code — but the process logic is comparable. A manufacturer already working with EU FMD serialization can complete the adaptation in 4–6 months with proper planning. The one thing not to defer is integration testing: it is the most unpredictable stage in terms of timeline.


            Regulatory basis:

            1.. Methodological Guidelines for Working with Serialized Medicinal Products (version 1.8)
            2. Federal Law No. 61-FZ of 12.04.2010 «On the Circulation of Medicinal Products» (as amended 29.12.2025)
            3. Government Resolution of the Russian Federation No. 1556 of 14.12.2018 «On Approval of the Regulation on the System for Monitoring the Movement of Medicinal Products for Medical Use» (as amended 29.09.2025)
            4. Government Resolution of the Russian Federation No. 577 of 08.05.2019 «On Approval of the Fee for Services for Providing Marking Codes»
            5. GOST R ISO/IEC 16022-2008 «Automatic Identification. Bar Code Symbology. Data Matrix Specification»

            This page in Russian→