Meetings

Schedule

Meetings occur every second Tuesday at 9:00am CET. Advance notice will be provided for any changes.

• Zoom: https://us06web.zoom.us/j/82645920209?pwd=VD2EsPFaPajLq0Tfw2oRPe6QpJRPz9.1 
• Calendar: https://www.addevent.com/calendar/2h0rbdqvjmhs 

History

Click on a meeting date to see detailed minutes.

07 Apr 2026

Quick recap

The meeting focused on reviewing merge requests and discussing technical implementations for the KTDE (Korea Trade Data Exchange) project. Nis presented two main merge requests: one creating a compliance page to compare document requirements with KTDE specifications, and another addressing linked data references with over 300 terms that needed resolution. The team discussed challenges with document naming conventions and context file structure, debating whether to use one context file per document or a single comprehensive file. Several new documents including preferential certificates of origin and shipping instructions were discussed, with the team agreeing to merge them despite some test failures due to the “chicken and egg” problem with context resolution. The meeting also covered broader topics including trust registers, W3C Verifiable Credentials work, and the need for interoperability testing as the specification is adopted by software vendors.

Next steps

• Nis: Fix the linked data context merge request and resolve deployment/test issues out of band, then show the results in the next meeting.
• Nis: Add a field or mechanism to the compliance tool/page to capture reasons for deviations from KTDE requirements.
• Nis: In the folder containing the copied KTDE requirements documents, add a README specifying the source of the documents, as discussed with José and Henri.
• Hans: Post questions about the best way to engage in repo discussions in the open (on the repo) rather than via email.
• Steve: Continue gathering quantitative business impact data (e.g., trade costs, revenue leakage, trade finance gap metrics) for the trade finance specific section and report progress by next meeting; invite others to participate.
• Rudyhemeleers: Contribute details or requirements to the captured issues regarding step-by-step guides for both contributing to specs and implementing specs, and participate in the relevant GitLab issues.
• All team members (especially Walid, Benedict, Alina, and others without GitLab accounts): Join the GitLab repository and begin commenting on tickets/issues to increase engagement.
• Stephan: Write an article comparing various tech stacks (e.g., W3C vs ACDC) and, when ready, provide it to be linked from the spec.
• Steve and Rudyhemeleers: Discuss offline the future of the UN/CEFACT vocabulary (Buy Ship Pay) and report relevant discussions to the team in the next meeting.
• Nis: Show the linked data page/tool demonstrating live resolving during the next meeting.
• Nis: Consider splitting future large merge requests (e.g., tooling and term fixes) into smaller, focused merge requests for easier review.
• Nis: Add mechanism/tooling to capture feedback or decisions for non-implemented KTDE requirements (i.e., reasons for omissions).
• Nis: Add mechanism/tooling to highlight when terms are implemented in the spec but missing in KTDE, for completeness tracking.
• Nis: Address the issue of currency code missing due to outdated document version by updating to the latest KTDE version.

Summary

Repository Discussion Guidelines Meeting

The meeting began with participants joining and Nis emphasizing the importance of conducting discussions in the repository to ensure transparency and engagement from all contributors. Hans agreed to continue their previous conversation about the best approach for this in the open space after the meeting. Steven briefly mentioned reviewing Nis’s merge request and introduced Nis to present updates. The conversation ended with a reminder about the code of conduct, emphasizing respectful conversation and the freely available nature of IP contributed to the repository.

Document Comparison Feature Updates

Nis presented two merge requests for review: one adding a page to compare documents with KTDDE requirements, and another addressing linked data references. Steven explained that these changes aim to improve the quality of their output by tracking implementation progress and ensuring correct vocabulary mappings. Nis noted that while the current comparison lists whether requirements have been implemented, they should also capture intentional deviations. The team agreed to proceed with merging both requests, with Nis mentioning that over 300 terms initially didn’t resolve properly but had been reduced to about 100 through recent fixes.

Vocabulary Name Change Concerns

José raised concerns about cosmetic changes to property names in the vocabulary, particularly regarding the renaming of “issue date” to “issue date time,” arguing it could confuse implementers. Phil pointed out an inconsistency where the renamed term still used the original type (XSD date) rather than the corresponding type for the new name (XSD date time). Steven suggested that the current merge request should be approved and released to facilitate these discussions, as it provides a table for examining vocabulary mappings that were previously buried in code.

Merge Request and Testing Issues

Nis discussed fixing an issue with bad casing and proposed splitting the merge request into two parts, one for producing the page and another for fixing terms. José approved of the current merge request as a starting point for analysis. Nis mentioned there would be more work to be done and planned to fix conflicts before merging. The team also discussed failing tests for a new document, with Nis explaining it was a chicken and egg problem due to the lack of context and suggesting a way to fix the tests to avoid red crosses.

Document Merge and Standards Guidance

The team discussed merging two documents despite test failures, agreeing to proceed with the merge to create a first draft that can be reviewed on the site. They identified the need for both implementation guidance (how to use the standards) and a step-by-step guide for contributing to new standards documentation. Nis agreed to capture these requirements as issues and requested details from Rudy on how he wants to see these guides implemented.

GitLab Requirements Documents Integration

The team discussed adding requirements documents to the GitLab repository. José raised concerns about copying documents from their original location and maintaining the source of truth. Henri clarified that the documents are public and open, with only minor updates made recently. The group agreed to copy the documents to the repository while adding a reference to the source in the README. Nis will implement this change and merge it in the next update.

UNVTD Specification Progress Discussion

The team discussed progress on the UNVTD specification and related standards. Steven shared insights about trust registers and digital verifiable proof of membership, highlighting opportunities for existing national registers to participate in the global trust landscape. Phil mentioned W3C’s Verifa Credentials Working Group and its work on entity recognition and VC frameworks, noting APAC-friendly meeting times. Nis presented a tool for checking KTDE compliance against UNVTD requirements, identifying missing elements like currency code that were later confirmed to be present in recent updates. The team discussed context file structure, debating whether to use one context file per document or a unified context file, with considerations for versioning and interoperability. They also addressed the need for testing interoperability across different software implementations and agreed to continue discussions on vocabulary management and technical stack comparisons in future meetings.

24 Mar 2026

Quick recap

The UN Verifiable Trade Documents team held their fortnightly meeting to review progress and discuss technical updates. Nis led the review of merge requests, including updates to conformance testing, README improvements, and schema updates based on the latest KTTE spreadsheet. The team discussed potential improvements to the UNTD vocabulary, with Steven suggesting modernization using AI tools like Claude to address issues with abstraction and object/predicate confusion. A significant portion of the meeting focused on project access issues, particularly adding Hans as a contributor to the GitLab repository, which was successfully resolved during the meeting. The group also discussed the addition of a delivery note document to their scope, with Hans and Stephan offering to provide specifications for this important trade document. The conversation ended with plans to continue development work and address remaining technical issues in the next session.

Next steps

• José: Update Node version requirement to Node 24 in the project README and resolve any related build issues (Issue 33)
• Nis: Create an issue to fix the test that allowed incorrect casing (capitalization) in property names, and address broader casing issues in the test suite
• Nis: Work on a script and PR for a comparison page showing deviations between current implementation and latest KTDE spreadsheet, including gaps and additional elements needed
• Hans and Stephan: Provide the delivery note specification/content (including required data elements) and raise an issue for its inclusion in the project
• Nis (and Sin Yong): Add Hans (and check for José) as project contributors to the GitLab repository to enable them to create merge requests
• Hans: Once access is granted, raise an issue and provide content for the delivery note document
• Nis: Close issue 20 (shipping manifest/packing list confusion) with a note clarifying that the correct document (packing list) has already been addressed

Summary

UNVTD Project Progress Update

The team discussed ongoing work on the UN Verifiable Trade Documents (UNVTD) project, with Nis providing updates on recent progress. Nis explained his approach to conformance testing, deciding to leverage existing tests rather than creating new ones, and described how to subject files to these tests through a new page. The team also briefly discussed product passports and business wallets, with Steven and Hans agreeing that there’s no strict requirement to place them in the same wallet system.

Credential Testing Pull Request Merge

Steven and Nis discussed merging two pull requests related to credential testing. They agreed to start with basic tests for credential schema and vocabulary compliance rather than implementing more complex features like multiple credential linked data graph verification. Steven mentioned positive feedback from ICC and ADB regarding the project’s value as an implementable specification. Nis approved merging both pull requests without objections.

Static Website Deployment Planning

The team discussed technical aspects of building and deploying a static content website, with Nis explaining the specific requirements around Node version and folder structure. Steven emphasized the importance of creating implementable, testable content that can be understood by software development companies like SAP and Xero, rather than just providing general guidance. The team agreed to update from Node 18 to Node 24, with José taking responsibility for making this change, and they identified an existing issue (number 33) that needs to be addressed in a future meeting.

Schema Updates and Vocabulary Discussion

Nis presented updates to the schema, including new elements from the KTTE version and discussed the addition of an Excel file as a main source of requirements. The team reviewed specific details about certificate of origin, including issuing authority and competent authority, with Steven asking for clarification on the differences between these concepts. José provided input on mapping conventions and vocabulary usage, particularly regarding capitalization in class and property names. Steven raised concerns about the limitations of the UNCAT vocabulary being too generic and potentially needing modernization for better mapping capabilities.

UN/CEFACT Vocabulary Modernization Proposal

Steven proposed modernizing the UN/CEFACT vocabulary by moving it to a GitLab repository and refactoring it to improve clarity and usability. He identified issues with the current process, including confusion between objects and predicates, and suggested using Claude Code to streamline the vocabulary. José acknowledged the size of the UN/CEFACT vocabulary and suggested focusing on relevant classes and properties for the UN/BT project. Steven expressed interest in leading this effort but sought support from the group.

Vocabulary Management Strategy Discussion

The team discussed vocabulary management for their project, with Nis noting arguments both for and against creating a new vocabulary versus using existing standards like UNTD. Henri shared that their previous DSI KTDDE project used existing UNTD data elements and definitions where possible, with only about 40 out of 200 elements requiring new definitions. The team then reviewed and approved merge requests 27 and 28, with Nis accepting merge request 27 despite a casing error in the test, which Steven agreed to fix. Nis also mentioned working on issue 21, which involves creating a script to compare their current vocabulary with the latest LTT spreadsheet and generate a single page highlighting deviations for feedback to DSI.

KTDDE Gap Analysis Planning

The team discussed creating a gap analysis summary page to identify missing KTDDE elements per document, which would be converted into tickets for enhancement. Henri clarified that KTDDE is not a standard itself but a collection of standards, and while it aims to identify key data elements used across documents, it’s not intended to be exhaustive like UNVTD. The team agreed to prioritize shipping manifests alongside invoices and waybills, with Nis volunteering to take on this priority adjustment task.

Shipping Documentation Requirements Discussion

The group discussed the difference between shipping manifests and packing lists, with Nis clarifying that manifests cover entire vessels while packing lists show contents of individual shipments. Hans identified the missing delivery note as an important trade document not included in the KTDE list, which Henri explained was based on an existing UNECE report rather than a comprehensive business model. The discussion concluded with agreement that while KTDE was never intended to be fully implementable, the current working group could add additional documents needed for practical implementation, with both groups working to maintain synchronization between their efforts.

Delivery Node Specification Discussion

The team discussed creating a delivery node specification and JSON structure, with Hans and Stephan agreeing to provide this content within the next few days. They addressed access issues for project contributors, with Steven explaining the process for becoming a GitLab contributor and Nis granting Hans developer access. The group also briefly mentioned a study involving invoice and delivery note automation, though specific details were not fully discussed.

10 Mar 2026

Quick recap

The meeting focused on reviewing and discussing the development of a UN digital trade documentation system, with participants examining technical architecture, vocabulary mappings, and content structure. The group debated how to handle semantic mappings between domain-specific terms (from ICC DSI) and global vocabularies like schema.org and UN/EDIFACT, with concerns raised about potential risks and the need for careful validation of mappings. Henri confirmed recent updates to the ICC DSI data elements and offered to facilitate feedback channels to the ICC secretariat. Harri shared ongoing pilot work in Finland regarding semantic mapping of trade documents, while Nis emphasized the importance of avoiding duplicate work and coordinating efforts. The conversation ended with an agreement to address technical issues through pull requests and maintain open communication channels for further collaboration.

Next steps

• Steven: Fix the missing portable credentials page and other broken links in the site content, then commit the fixes to the relevant pull request by tomorrow.
• Nis: Merge the minutes pull request.
• Steven: Notify Nis and team via channel when the fixes are committed so Nis can proceed with merging the updated pull request.
• Harri: Send to the mailing list any materials or decisions regarding how ICCDSI terms map to various vocabularies (e.g., schema.org, UN/CEFACT, GS1), so the group can review and potentially reuse this mapping work.
• All participants: Review published content on the site and raise tickets or send text/content suggestions for changes or additions, especially for empty or draft pages.
• Henri: Double check and, if possible, provide the email address/contact for the ICCDSI Secretariat for formal feedback on data element gaps/updates.
• All participants: Raise issues in the issue tracker with specific needs, questions, or tasks related to document development and mapping, to coordinate ongoing work.
• Steven and Sin Yong: Collaborate to produce and publish additional business use case and architecture content before the next meeting, with a draft disclaimer on all pages.
• Nis: Update the ICCDSI Excel file in the repo with the latest version, as referenced in the linked issue.

Summary

Website Information Architecture Updates

The team discussed updates to the website’s information architecture and content structure. Steven shared his work on restructuring the site, including adding content about goals, principles, and portable credentials. He mentioned some broken links and promised to fix them and share a link to the portable credentials page after the call. The team also briefly touched on the importance of portable credentials in managing data transformations and their legal record status.

Content Management Collaboration Workflow

The team discussed collaboration methods for content management, with Steven explaining that changes can be made locally and pushed as requests, similar to Git workflows. Nis emphasized that anyone should feel empowered to contribute without needing to understand the technical details, suggesting that content changes can be submitted via tickets or directly to Nis. José raised concerns about the infrastructure requirements for document management, suggesting that even simple services like email or REST servers would be necessary. Steven mentioned using AI assistance to draft content, which he proposed as a way to quickly generate a complete site for discussion and refinement.

Digital Credential Exchange Evolution

The discussion focused on the evolution of digital data exchange, particularly how portable credentials eliminate the need for specialized platforms or networks to transfer documents between parties. Steven and José agreed that while networks like the internet are necessary for data exchange, the paradigm shift is that credentials can now be sent directly via email or APIs without requiring access to specific platforms or hubs. José emphasized the importance of interoperable data exchange and the value of commerce models, while Steven highlighted how this approach breaks down historical barriers of digital data exchange that required agreeing to use specific platforms like TradeLens.

Trust Protocols for Small Enterprises

The group discussed the importance of developing simple, lightweight, and verifiable protocols for trust and data standards, particularly for small enterprises. José and Steven emphasized the need for clear language and agreed to collaborate on writing and refining these standards. Boharald shared his experience as a small enterprise user of a digital wallet for invoicing, highlighting the importance of trust and identification credentials. Steven stressed the dual focus of the project: developing trust protocols and ensuring document authenticity, noting that while semantic understanding becomes easier with AI, the challenge of verifying document integrity grows.

Documentation Content Development Process

The team discussed content development and review processes for their documentation project. Steven proposed publishing draft content with clear disclaimers and allowing iterative improvements through review comments, which Nis supported. Sin Yong and Steven agreed to collaborate on business use cases and architecture content before the next meeting, while Nis would focus on verifiable trade documents. The team also touched on the need to clarify minimum toolsets required for different functionalities and highlighted UNVTD’s ability to send data across analog links.

Invoice Data Mapping Standards

The meeting focused on mapping data fields in invoices to global vocabularies like schema.org and UN/CEFACT. Steven and José discussed the challenges of ensuring accurate mappings, particularly for terms like “consignment” and “trade terms.” They agreed that while linking to universal definitions is important, the actual risk lies in incorrect mappings being used by other parties. José emphasized the need for a review of all mappings produced, while Steven suggested that most users will focus on basic mappings to their internal systems rather than global vocabularies.

Domain-Specific Mapping to Schema.org

The group discussed the technical architecture of mapping domain-specific terms to schema.org vocabulary, with Steven expressing concerns about potential risks in the mapping process. Nis and José agreed that while the group should take responsibility for checking mappings, the context file helps streamline the process by providing most of the mapping. José suggested discussing property name aliasing in schema.org, and Stephan mentioned the ICC’s work on standardizing trade document terms and data elements, which the group has incorporated into their context files.

ICCDSI Data Vocabulary Coordination

The team discussed the reuse of ICCDSI data elements for trade documents, with Henri confirming recent updates and maintenance of the KTDDE vocabulary. Harri shared ongoing pilot work mapping ICCDSI terms to existing vocabularies, particularly schema.org and GS1, with plans to discuss further on Friday. The group agreed to coordinate on vocabulary mappings rather than duplicate efforts, with Nis requesting Harri to share relevant mappings via the mailing list. The conversation ended with an agreement to address pending issues in the next call, and Nis confirmed he would merge Steven’s pull request after Steven makes additional commits to fix identified problems.

24 Feb 2026

Quick recap

The meeting focused on restructuring the UNVTD site’s information architecture to better serve both business users and technical implementers. The group discussed keeping the core document schema simple while allowing for extensions to address industry-specific needs, with agreement to maintain separate guidance for complex use cases like maritime trade. A significant discussion centered around the role of business wallets, with Bo Harald volunteering to write the wallet section for the architecture page, though the group agreed wallets should be supported but not required for implementation. The team also decided to focus primarily on cross-border trade use cases rather than domestic implementations, acknowledging potential conflicts between decentralized models and government surveillance requirements.

Next steps

• Nis: Create a ticket about adding clear instructions on how to join and use UN GitLab, and consider linking to the existing UNTP guidance page.
• Steven: Attach Abhijit’s maritime trade input/report (ChatGPT output) to a relevant ticket for further discussion.
• Bo Harald: Write the “wallets” section for the architecture page and engage the Open Wallet Foundation as appropriate.
• Steven: Propose changes to the site navigation/information architecture, send out a link for review, and make a pull request for the new structure.
• Steven: Send out an email when the new information architecture is ready and request volunteers for writing different sections of the site.
• Nis: Move the “architecture” section to appear after “governance” and before “business use cases” in the site structure, and add relevant subheadings under “architecture”.
• Steven and Sin Yong: Collaborate on writing the architecture section (including new mental model and subheadings).

Summary

Trade Documentation Site Architecture Review

The meeting focused on discussing the architecture and content of a trade documentation site. Steven noted that while there was some technical content, there was a lack of business patterns and use cases. The group reviewed the current state of the site, which included specifications, meetings, and initial documents created by Nis. They discussed the need to structure the site in a way that would be valuable for both business users and technical implementers. The conversation ended with a plan to continue developing the site’s content and structure collaboratively.

Website Restructuring and GitLab Access

The team discussed restructuring their website and improving access to the UN GitLab. Steven proposed creating a landing page with clear information about the project’s purpose and target audience, along with sections on governance, meetings, and architecture. He suggested adding a test service for document compliance and an implementation register. The group also touched on the need to document high-value use cases and clarify the titles of existing sections. Walid mentioned adding a proposed structure for a letter of credit and linking it to a bill of lading. The conversation ended with an open invitation for feedback from the team members.

Clarifying Cross-Border Trade Architecture

Sin and Steven discussed the need to clarify the architectural concepts and mental models related to cross-border trade and document exchange. Sin emphasized the importance of explaining the differences between the current and previous models to avoid misunderstandings during meetings. Steven suggested elevating the architecture section to a top-level heading with subsections to improve clarity. Nathan added that a similar standard, the Digital Container Ship Register, exists but differs from their approach, highlighting the need for better explanation of these differences.

Digital Document Standard Development

The group discussed the development of a new digital document standard, focusing on its unique value proposition and relationship to existing standards. They explored how to handle industry-specific variations and legal differences across regions, with Nathan and Steven expressing concerns about creating overly complex documents that could replicate the complexity of older systems. The team agreed to start with high-value use cases like customs compliance and maritime trade, while acknowledging that some level of customization might be necessary to accommodate different industry needs.

Core Document Extension Strategy

The group discussed keeping the core document standard simple while allowing for extensions to address specific use cases or local nuances. Nis explained that JSON allows for additional attributes that can be ignored by readers if unknown, and suggested allowing extensions to accommodate local variations. Steven agreed that extensions should be allowed but questioned whether to document common shared patterns like Bulk Marine Transport. The discussion also touched on the challenge of rendering human-readable documents when dealing with auxiliary parameters, with Steven suggesting that issuers could include rendering templates for their specific needs.

Maritime Trade Simulation Insights

Abhijit shared insights from his simulation work on maritime trade, highlighting complexities around bills of lading and ownership changes, particularly in trades between different regions. Steven agreed to attach the ChatGPT-generated report to a ticket for further discussion, noting the need to keep context-specific variations out of the core system and address them in business use cases. Walid emphasized the importance of simplicity while maintaining effectiveness and usability, suggesting versioning for documents and protocols and proposing leveraging the underlying JSON Linked Data structure to handle different modes of transportation.

Version Control and Wallet Integration

The group discussed version control and documentation practices, with Steven explaining their approach of using version numbers like 0.5 for public review and maintaining a work-in-progress version alongside stable releases. Bo Harald emphasized the goal of converting as many documents as possible into verifiable machine-readable credentials, while noting that this initiative aligns with discussions in the Open Wallet Foundation about developing a global business wallet model. The team agreed to prioritize certain ICC BSI document types for implementation, starting with high-priority items like invoices and shipping manifests, and discussed the need to support wallets while maintaining the ability to access credentials without requiring wallet-dependent systems.

Wallets in Trade Documentation Architecture

The group discussed the role of wallets in trade documentation, with Bo Harald sharing his experience using business wallets in Europe for invoices and credentials. Steven emphasized the need for an architecture that allows a pragmatic pathway from current systems to future wallet-based solutions, acknowledging that not all parties involved in a transaction need to have a wallet. The discussion concluded with an agreement that while wallets should be supported, the architecture should not depend solely on wallets, and this topic would be addressed in the architecture section of their strategy.

Business Wallets: Privacy and Integration

The group discussed the differences between personal and business wallets, with Phil expressing concern that privacy-focused technology designed for individual use might not be suitable for commercial purposes. Bo Harald explained that the European Union has shifted focus to business wallets, which can be used with lower assurance levels than personal wallets, and predicted that these would eventually merge into a global business wallet. Steven agreed to include wallet considerations on the architecture page but emphasized that the focus should not be on demanding wallets, as alternative patterns for data exchange without wallets should also be supported.

Website Navigation Architecture Discussion

The team discussed the structure of a navigation architecture for a website, with Steven proposing a pull request that would include sections on governance, architecture, and business use cases. They debated whether to include domestic e-invoicing use cases, with Stephan suggesting they should be open to both domestic and cross-border trade applications, while Sin advised focusing on cross-border trade to manage scope and avoid policy complications. The team agreed to move the architecture section to appear before business use cases, and Nis committed to making this change in the next commit.

10 Feb 2026

Quick recap

The meeting focused on discussing the exchange architecture for verifiable credentials in international trade, with particular emphasis on whether digital wallets are necessary for document exchange. The group explored different models for sharing trade documents, including Singapore’s approach that supports both human-readable and machine-readable formats while accommodating varying levels of digital readiness among trading partners.

The discussion highlighted that wallets may be useful but the exchange architecture should not depend on wallet adoption, as many partners lack digital infrastructure. Kokichi-san’s feedback on invoice formats was noted but not fully addressed due to time constraints.

The meeting concluded that the main challenge is overcoming preconceptions about digital document exchange and demonstrating that a single document format can work across different technical capabilities without requiring bilateral agreements.

Next steps

• Steven: Send instructions to participants on how to sign up for GitLab and update the relevant page with signup/link information.
• All regular meeting participants: Sign up to GitLab to comment on tickets and participate in issue tracking.
• Steven: Paste Kokichi Watanabe’s latest email feedback into the relevant GitLab ticket regarding invoice feedback.
• Kokichi Watanabe (and other subject matter experts): Review rendered human-readable document templates on the site and provide comments (preferably as GitLab tickets) on missing or required content for trade documents.
• All participants: Write comments or questions in GitLab tickets (once signed up) to continue discussion on document content and exchange models, rather than relying only on email.
• Steven: Update the meetings page with a link or instructions on how to sign up to GitLab.

Summary

Invoice Format Standardization Discussion

The meeting reviewed human-readable presentations of invoice formats and associated business cases. Steven explained a new feature that applies UN Layout Key standards to render documents in a more user-friendly format, confirmed by Sin Yong as based on UNECE Recommendation No. 1.

The group discussed the GitLab signup process, with Steven noting that approval typically takes 2–3 days and is primarily for bot prevention. The session concluded with plans to address business feedback on invoice content, with Kokichi-san’s input to be discussed next.

Digital Trade Document Evolution

The group examined both human-readable and machine-readable trade documents. Steven presented a diagram showing how multiple actors in a value chain interact with a commercial invoice.

He outlined challenges in moving from paper to digital and proposed different exchange models, including:

• separate documents with QR codes, and
• single documents with hosted verification services.

Participants discussed possible confusion with QR codes and the importance of trust in verifier services. Steven emphasized the need to help users understand the difference between PDFs and digital renderings, including options for personal verification services.

Digital Wallet Exchange Architecture Discussion

The group discussed exchange architecture for trade documents, focusing on the role of digital wallets. Bo Harald and Sin Yong shared insights from European wallet initiatives and the Singapore verifiable credentials model.

Participants agreed the architecture should support wallets but must also function without them. Steven stressed the need for a scalable approach that accommodates varying levels of digital readiness among trading parties.

The discussion emphasized enabling easy document exchange—similar to how passports function—without requiring universal digital capability. The meeting concluded with encouragement to continue discussion via GitLab tickets and share insights or “lightbulb moments” about the proposed exchange model.

27 Jan 2026

Quick recap

The team discussed a quantitative analysis of economic impact for grid and UNVTD implementation at scale, reviewing PDF documents containing trade metrics and methodology validation approaches. They explored the development of business cases for multilateral development banks, including data collection, sample cases, and advocacy strategies. The group also addressed technical specifications for verifiable credentials, test playground considerations, and rendering templates for human and machine readability in trade documents.

Next steps

• steven: use a better markdown to PDF converter and repost all PDF documents with improved formatting
• All participants: download and review the uploaded PDFs, check methodology and sources, and provide critical feedback (with focus on key countries/methodology, not full document review)
• Sin: extract and contribute a business flow diagram showing how a certificate of origin is used in a business scenario, and add technical exchange details as a comment or file in the relevant repo/thread
• Nis: create a placeholder/template for capturing implementer metrics and usage data, referencing the UNTP approach
• steven: lead/coordinate the development of a potential UN policy recommendation document (to be decided if/when to proceed, based on business case progress)
• Nis: add a section to the presentation (as referenced in the meeting)
• Nis: take a first pass at creating guidance/tutorial sections in the spec, including mapping from known software suppliers to schemas, tutorials, and best practices
• steven: look into Zoom settings before the next meeting to avoid the need for manual admittance to the call
• All: comment/discuss further on the rendering templates issue (human-readable rendering) in the relevant issue thread

Summary

Grid and UNVTD Economic Impact Analysis

The meeting focused on discussing a quantitative analysis of the potential economic impact of rolling out grid and UNVTD at scale in a given country. Steven presented several PDF documents generated with the help of Claude Code, which contain metrics such as export-import volumes, ad valorem cost of trade, revenue leakage estimates, and cost of trade finance access. He invited the group to download and critique the documents, which are based on authoritative data sources. Steven’s goal is to develop a methodology to assess the impact of implementing these solutions on various economic indicators, in order to create a business case for investment on a country-by-country basis.

Trade Data Processing Methodology Review

The team discussed issues with PDF rendering of trade volume data and agreed to use a better PDF converter. Steven explained he had processed large trade databases from World Bank and UN sources into structured formats, though some files were too large for Excel. The group aligned on focusing on methodology validation rather than verifying every data point, with Sin suggesting to quantify the contribution of two projects to reducing trade gaps and leakages. Steven’s ultimate goal is to develop a business case generator for multilateral development banks, which would need to be defensible and plausible in its projections.

Investment Cases for Grid Impact

The team discussed the final delivery of their project, which involves generating investment cases for countries by analyzing the impact of grid and UNVTD implementation on various measures like access to fair names. Steven explained that the process would start with data collection and methodology development, followed by creating sample business cases that could be tested with multilateral development banks. Nis questioned whether this would be part of the specification or a separate deliverable, to which Steven responded that it was a group decision. Peter suggested using the analysis for advocacy and communication purposes, potentially engaging development banks and UN agencies for review and awareness raising, though he noted that immediate policy changes were unlikely.

Product Uptake Measurement Discussion

The team reviewed a single merge request from Nis containing meeting notes from the previous session, which was approved without objections. They discussed an issue about measuring uptake of their products, with Steven clarifying that the primary audience is member states. Nis noted the challenge of measuring usage due to privacy concerns and mentioned a similar discussion in UNCP.

Testable Specification and Metrics Development

The group discussed developing a testable specification with test services and maintaining an implementer’s register to track the impact of UNTP and other platforms. Steven explained they want to collect anonymized metrics from implementers, such as the number of invoices issued, to measure outcomes like cost reduction and tariff collection improvements. Nis agreed to create a placeholder template for capturing this data. The discussion then shifted to decoupling from communication channels, where Steven suggested using real-life examples to demonstrate how digital product passports can be exchanged through various methods, similar to how a physical passport works.

Digital Trade Document Interoperability

The team discussed creating examples of digital trade flows, focusing on how certificates of origin and other trade documents can be exchanged without relying on traditional digital wallets. Sin agreed to provide a business flow diagram showing how certificates of origin are used in practice, while Steven emphasized the importance of demonstrating both wallet-to-wallet transfers and publish-discover scenarios without wallets. Bogharald shared insights about the European business wallet rollout, noting that wallet-to-wallet e-invoicing is being implemented globally with about 30 interoperable wallets available. The group agreed to focus on practical examples rather than extensive testing services, with the goal of helping implementers verify their solutions are correct.

Verifiable Credentials Test Playground Discussion

The group discussed implementing a test playground for verifiable credentials, with Steven proposing a system to check schema compliance and vocabulary alignment. Nis expressed concerns that such a test playground might inadvertently favor certain technical implementations over others, potentially creating a de facto standard. Hans agreed that flexibility was important, but did not oppose the idea of a test playground. The group acknowledged that while market choice is valuable, some form of testing and validation is necessary to ensure interoperability. Nis invited anyone interested to contribute to the development of the test playground, and noted that Steven would need to be assigned to work on policy recommendations.

Technical Specification and Policy Discussion

The team discussed whether to accompany a technical specification with a formal UN policy recommendation to member states, with Steven suggesting this could be a separate project and might emerge from economic analysis. They also addressed the need for guidance on mapping information from known software suppliers to their schemas, with Steven explaining that this could be light or heavy depending on requirements. The team agreed to add a section to a presentation and discussed rendering templates for verifiable credentials in a human-readable format. Additionally, they noted issues with Zoom meeting access and agreed to adjust settings to prevent future attendance problems.

Credential Rendering Method Discussion

The team discussed the need for credentials to be both human and machine readable, particularly in trade documents with multiple parties. Steven suggested providing examples with rendering templates, while Nis expressed concerns about the technology method used for rendering. Sin emphasized that the issuer should decide the rendering method, but the project team needs to pick a method for delivering examples. The group agreed to continue the discussion and meet again in two weeks.

13 Jan 2026

Quick recap

The UNVTD team meeting focused on reviewing and approving pull requests for their specification repository, which contains standards for verifiable trade documents like invoices and shipping manifests. The team discussed technical aspects of document identification, data validation, and the balance between W3C and IETF standards for verifiable credentials. They agreed to support both technologies while avoiding unnecessary complexity. The group also addressed the need for business-focused content, including sections on trade finance and customs, and discussed creating business value propositions to demonstrate the benefits of their specifications. Several team members expressed interest in contributing to these business-focused efforts, including Alina and Benedict. The conversation ended with a reminder about the upcoming two-week interval before the next meeting.

Next steps

• Nis: Merge outstanding pull requests with conflicts and resolve merge conflicts offline
• Nis: Add screenshots of specification changes to future pull requests for better clarity
• Nis: Create a new issue/section to discuss and document the node-carrying aspect of linked data in documents (per discussion with Steven)
• Steven: Write initial text/content for the customs section, particularly regarding how verifiable documents support new customs authority use cases
• Nis: Write initial text for the section on balancing technical recommendations regarding W3C vs IETF approaches (with input from Hans)
• Hans: Provide input on balancing technical recommendations, particularly regarding IETF/SD-JOIN approaches
• All interested parties: Email Steven to express interest in contributing to the business value/impact assessment document
• Alina: Contribute to writing a section on business/legal aspects (specific section to be determined)
• Benedict: Send email to mailing list to express interest in participating in business value/impact assessment
• Steven: Create/organize a Google Docs library for business value propositions/impact stories (for non-technical contributors)

Summary

UNVTD Trade Document Standards Kickoff

The meeting served as a kickoff for the UNVTD team, emphasizing the development of standards and tests for a library of verifiable trade documents, such as invoices, waybills, and shipping manifests. Steven explained the project’s focus on creating an implementable toolkit based on the UN vocabulary and ICC Digital Standards Initiatives, highlighting its connection to decentralized architectures and identity verification. He noted the involvement of Spain and India as committed implementers and the complementary nature of the project with another initiative focused on trust and identity. Nis and Sin Yong were set to discuss technical and business issues, with Nis planning to share their screen for further details.

Trade Document Trust Registry Update

The meeting began with introductions from participants, including Phil Archer from GS1, Benedict Itegbe from the Nigerian Export Promotion Council, and Abhijit Muite, a maritime expert. Steven explained the connection between three related projects: the commercial and logistics trade documents, the Identity Trust Register, and the United Nations Transparency Protocol. Nis discussed a pull request related to the trust registry and proposed merging it, despite some previous comments, as no additional changes were suggested. The group agreed to move forward with merging the pull request, with any further issues to be addressed in subsequent discussions.

Pull Request Merge and Design Discussion

The team discussed merging a pull request, with Steven suggesting that it’s generally acceptable to merge at this stage unless there’s substantial disagreement. They also talked about the importance of designing documents with graph-based data relationships in mind, particularly for UN/CEFACT projects. Nis agreed to merge the pull request and mentioned that a separate discussion about identifier design would be more appropriate. The team then approved some rules for decentralized identifiers and agreed to add a page for capturing meeting notes and recordings.

KTDDE Document Review Process

The team discussed the importance of reviewing open issues and merge requests before meetings to facilitate more productive discussions. Nis explained the current focus on eight initial documents from KTDDE’s first batch and clarified that the project is structured like a website, with changes tracked through merge requests that update the specification site. Alina sought clarification on the issuer identifier concept, which Steven elaborated on by explaining its link to decentralized identifiers and its role in associating business parties with documents. Nis also mentioned the need to include screenshots to better illustrate changes to the specification in future discussions.

Validating Trade Document Definitions

The team discussed the importance of ensuring that published documents are technically valid in both schema and linked data vocabulary senses. Nis provided an example of how combining different data elements leads to a description, and mentioned adding rudimentary references to the trust registry. Steven suggested publishing the work and collaborating with Alina to contribute meaningful content. They also discussed the need for every data element in a trade document to reference a formal definition, with most pointing to UN vocabulary definitions. Nis emphasized the distinction between documents and JSON data objects, and proposed introducing a node-carrying aspect alongside the current text-focused approach.

Technical Specifications for Verifiable Documents

The meeting focused on technical specifications for verifiable documents, particularly invoices and customs declarations. Participants discussed the balance between technical details and business requirements, emphasizing the need for simplicity and interoperability. Steve highlighted the importance of business value propositions to drive adoption, and invited contributions from experts in various sectors. The group agreed to support both W3C verifiable credentials and IETF signed envelopes, while Hans and Mikael raised questions about semantic interoperability. The conversation ended with a call for volunteers to contribute to the business impact assessment section.

16 Dec 2025

Quick recap

The meeting focused on discussing the structure and approach for developing trade document specifications, with a key debate on whether to split the team into technical and business teams. The group decided to maintain combined meetings for now but conduct a survey to determine team preferences. Nis demonstrated how to use the GitLab repository for contributing to the specification, and the team reviewed several merge requests, particularly focusing on data modeling for invoices and the handling of issuer identifiers. The team agreed to use existing vocabularies where possible and to address gaps in the KTDDE model while keeping the specification focused and implementable. The conversation ended with a discussion of implementation guidance and trust registry integration, with an agreement to skip the next meeting due to holidays.

Next steps

• steven: Set up the team admin account so others can launch Zoom Meetings before the next meeting.
• Nis: Fix non-resolving linked data references in the commercial invoice merge request and address follow-up issues (e.g., missing/incorrect properties) before next review.
• Nis: Add an issue (or follow up) to address missing types throughout all documents, as discussed with José.
• Nis/steven: Contact Pamela and Oscar (or relevant KTDD contacts) to provide feedback on gaps/changes found in KTDD as the project progresses.
• Nis/steven: Run a survey on Slack to gauge interest in technical vs. business/adoption groups, and revisit the decision to split meetings after a few combined sessions.
• Nis/steven: Update the meeting schedule to skip the meeting in the middle of the holidays (30th December), and confirm the next meeting for 13th January.
• (Unassigned, but discussed as needed): Add implementation guidance sections to the spec (e.g., mapping from legacy software, tutorials, best practices, security, interop testing)—volunteers requested, but not yet assigned.
• (Unassigned, but discussed as needed): Add a short section with example on how to resolve a DID and reference the Grid (Global Registrar Information Directory) project in the spec.

Summary

GitLab and Zoom Access Setup

The team discussed technical issues related to setting up two-factor authentication on GitLab and managing Zoom meeting access. Steven agreed to set up the team admin account and resolve the Zoom host permissions, with Nis temporarily taking on the host role. The meeting began with 16 participants, and Steven noted they would wait for a few more minutes before starting.

Team Split Strategy Discussion

The team discussed splitting into two groups: a technical team focused on schema and artifacts, and a business/adoption team focused on value propositions. While there was general agreement on the split, Sin suggested keeping the groups combined initially until the agenda items become more distinct. The team agreed to run a Slack survey to determine group preferences, with Steven noting that at least half the group felt more business-centric. They decided to maintain combined meetings for now, with the possibility of splitting later when appropriate.

UN/CEFACT GitLab Contribution Process

Nis demonstrated how to use the UN/CEFACT GitLab repository to contribute to and discuss changes to the specification code, emphasizing the importance of using issues for permanent discussions rather than Slack. Nis explained the process of reviewing and merging requests, starting with a change to avoid duplicate information in the issuer object, and discussed a second merge request adding missing elements to the commercial invoice based on practical experience. The team agreed to further discuss the implications of these changes before merging them into the main branch.

Trade Document Data Modeling Approach

The group discussed the approach to data modeling for trade documents, with Steven explaining that KTDDE took a top-down approach analyzing 36 trade documents with around 400 data elements, while UN/CEFACT models contain thousands of fields. José raised concerns about potential repetition and modularization of properties needed in other documents, while Nis suggested keeping a log of changes from KTDDE. The group aligned on pursuing a simpler, more implementable model rather than creating an overly complex one, with Steven emphasizing that recipients typically only need fields necessary for accounts payable updates.

Trade Document Data Modeling Discussion

The team discussed data modeling approaches for trade documents, focusing on whether to use a superset of all possible data elements or a core set with extensibility through linked vocabularies. They agreed to use existing vocabularies where possible and add missing types subsequently. The group reviewed merge requests, addressing issues with unresolved identifiers and data modeling. They decided to merge some requests despite technical inaccuracies, with plans to fix them later. The team also discussed implementation guidance and trust registry integration, agreeing to add a brief section on resolving DIDs to the specification. They concluded by deciding to skip the next meeting due to holidays and set the following meeting for January 13th.

2 Dec 2025

Quick recap

The meeting introduced the UN Verifiable Trade Document project, which aims to develop standards for cross-border trade facilitation through verifiable credentials and decentralized portable data packets. The team discussed implementation plans for trade document standards, including the structure of verifiable credentials and the importance of semantic authority, while reviewing a website containing a skeleton document for commercial invoices. The conversation ended with discussions about repository access and contribution processes, including the handling of merge requests and issues in the UNECE project repositories.

Next steps

• steven: send out slide pack from Senegal presentation to the mailing list after this meeting
• steven: create a team account before next meeting so Nis and Xinyong can co-host meetings
• steven: send out email after this meeting with links to the Global Registrar Information Directory project for those interested in joining
• steven: send out recording link for those who joined late
• Nis: add section with links to presentations on the website
• steven: ask Kevin at Secretariat to grant maintainer role for approving merge requests on this repository
• Team: register for UN GitLab access at the provided link to participate in raising issues

Summary

UN Trade Document Standards Initiative

The meeting introduced the UN Verifiable Trade Document project, with Steven explaining that it is a UN/CEFACT initiative focused on cross-border trade facilitation. He outlined that the project will operate in the open on UN GitLab, with all IP contributions to be made freely available to the public, and emphasized the need for active contributors while adhering to a code of conduct that prohibits commercial promotion. The project aims to develop standards for verifiable trade documents, with Nis and Sin Yong leading the day-to-day efforts, though Sin Yong was unable to attend due to family vacation.

Decentralized Trade Document Standards Project

The meeting discussed a project proposal for developing trade document standards using decentralized portable data packets, aiming to support cross-border trade by enabling verifiable credentials and human-readable templates. Steven explained the governance process, project scope, and technical approach, emphasizing the importance of measuring impact and uptake through collaboration with software vendors and early implementers. He highlighted the project’s focus on scalability and security, as well as its alignment with existing trade vocabularies and initiatives like the Global Registrar Information Directory, which has received commitments from India and Spain.

Verifiable Credentials Implementation Plan

The team discussed the implementation of a new project focused on verifiable credentials and decentralized identifiers (DIDs) for trade documents and business registrations. Steven explained that the project aims to create cryptographically secure credentials that can be used to verify business registrations and trade documents, with Spain and India already committing to implement the system. He also mentioned that there are about 5 more states in the deliberation process. The team agreed to share the presentation slides and links to the related project, and Nis was set to explain the process of raising issues and pull requests in the GitLab repository.

Verifiable Credentials for Trade Documents

The team discussed the structure of verifiable credentials, focusing on the W3C standard and its application to trade documents. They reviewed a website containing a skeleton document for a commercial invoice, which includes elements like identifier, business content, and digital signature. Steven shared links to relevant ICC and UN projects, while Nis explained the importance of semantic authority and publicly available references. The team agreed to refine the data model, with input from subject matter experts, and to improve the website’s presentation of the information.

UN Digital Product Passport Workflow

The team discussed a digital product passport project, with Steven sharing examples from a UN Transparency Protocol project that demonstrates human-readable and machine-readable data coexisting. Nis explained the project’s GitLab workflow, emphasizing that all changes and discussions should go through GitLab issues rather than Slack, as issues are better tracked and managed. The team agreed to use UN Recommendation Number 1 (LayoutKey) to inform rendering templates, and Nis outlined the process for gaining access to the UN’s specific GitLab instance at open-source.unicc.org.

UNECE Project Access and Contributions

The team discussed how to access and contribute to the UNECE project repositories, with Steven explaining that anyone can browse the UN open source projects but needs to register for an account to raise issues or contribute content. Nis demonstrated how to create an issue and shared a merge request to update the website’s styling to match UN standards, which Steven approved. The team agreed that most participants would only need basic registration access, while those more actively contributing might receive additional permissions, and Steven provided a link for UN-CEFACT expert registration.

Merge Request Process and Roles

The team discussed the process of handling merge requests and issues in their project repository. Nis demonstrated merging a pull request, which Steve could not approve due to his limited permissions. They agreed to break the rules and have Nis merge the request instead. Steve explained that the team would include both technical and business members, and emphasized that business people should not feel intimidated by the technical aspects. He encouraged them to focus on creating issues and commenting, while leaving the more technical changes to the team’s technical members. The conversation ended with Steve agreeing to send out a recording link for those who missed the early part of the discussion.