<!doctype html>
<html lang="en">
<head><base href="about:srcdoc"><script>(function(){function n(){parent.postMessage({t:'share:hash',h:location.hash},'*')}addEventListener('hashchange',n);addEventListener('message',function(e){if(e.source!==parent)return;var d=e.data||{};if(d.t==='share:setHash'&&typeof d.h==='string'&&d.h!==location.hash){location.hash=d.h}});addEventListener('DOMContentLoaded',function(){parent.postMessage({t:'share:ready',h:location.hash},'*')});})();</script>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>UNCTAD eRegistrations — Digital West Bank and Gaza (World Bank questionnaire)</title>
<meta name="description" content="Response to the World Bank vendor capability questionnaire (Report P176090, 2021), prepared by UNCTAD to promote the eRegistrations Digital Government Platform." />
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
<link href="https://fonts.googleapis.com/css2?family=Source+Serif+4:opsz,wght@8..60,300..700&family=JetBrains+Mono:wght@400;500;700&display=swap" rel="stylesheet" />
<style>
:root {
--paper: #F7F1E2;
--paper-bright: #FBF6E8;
--ink: #1E1A14;
--ink-soft: #3C3528;
--ink-light: #6F6552;
--rule: #D4C9A8;
--rule-strong: #A89A75;
--accent: #8C2E25;
--accent-deep: #5E1F18;
--green: #4F5C36;
--maxw: 78ch;
--gutter: clamp(1.25rem, 3vw, 2.5rem);
}
*, *::before, *::after { box-sizing: border-box; }
html { -webkit-text-size-adjust: 100%; scroll-behavior: smooth; }
body { margin: 0; }
table { border-collapse: collapse; }
section { scroll-margin-top: 2rem; }
body {
background: var(--paper);
color: var(--ink);
font-family: 'Source Serif 4', Georgia, 'Times New Roman', serif;
font-size: 18.5px;
line-height: 1.62;
font-weight: 400;
text-rendering: optimizeLegibility;
-webkit-font-smoothing: antialiased;
overflow-x: hidden;
}
/* Subtle paper grain — fixed, very low opacity */
body::before {
content: "";
position: fixed;
inset: 0;
pointer-events: none;
z-index: 1000;
opacity: .035;
mix-blend-mode: multiply;
background-image:
url("data:image/svg+xml;utf8,<svg xmlns='http://www.w3.org/2000/svg' width='240' height='240'><filter id='n'><feTurbulence type='fractalNoise' baseFrequency='1.2' numOctaves='2' stitchTiles='stitch'/><feColorMatrix values='0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 .9 0'/></filter><rect width='100%25' height='100%25' filter='url(%23n)'/></svg>");
}
a { color: var(--accent-deep); text-decoration: underline; text-decoration-thickness: 1px; text-underline-offset: 2px; }
a:hover { color: var(--accent); }
::selection { background: var(--accent); color: var(--paper-bright); }
.doc {
width: min(100% - 2rem, calc(var(--maxw) + 5rem));
margin-inline: auto;
padding-inline: var(--gutter);
padding-block: clamp(2rem, 5vw, 3.5rem) 3rem;
}
/* ---------- Masthead ---------- */
.masthead {
display: flex;
justify-content: space-between;
align-items: baseline;
gap: 1rem;
padding-bottom: .9rem;
border-bottom: 1px solid var(--ink);
font-size: .72rem;
letter-spacing: .14em;
text-transform: uppercase;
color: var(--ink-soft);
font-weight: 500;
}
.masthead .right { color: var(--ink-light); }
/* ---------- Hero ---------- */
.hero {
margin-block: 2.5rem 3rem;
}
.hero h1 {
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: clamp(2rem, 4.5vw, 2.95rem);
line-height: 1.12;
letter-spacing: -0.014em;
margin: 0 0 1.2rem 0;
color: var(--ink);
max-width: 28ch;
}
.hero .standfirst {
font-family: 'Source Serif 4', serif;
font-style: italic;
font-weight: 400;
font-size: 1.12rem;
line-height: 1.5;
color: var(--ink-soft);
max-width: 60ch;
margin: 0;
}
.hero .meta {
margin-top: 1.75rem;
padding-top: 1.1rem;
border-top: 1px solid var(--rule);
display: grid;
grid-template-columns: max-content 1fr;
column-gap: 1.5rem;
row-gap: .35rem;
font-size: .85rem;
max-width: 60ch;
}
.hero .meta dt {
font-family: 'Source Serif 4', serif;
font-size: .68rem;
letter-spacing: .14em;
text-transform: uppercase;
color: var(--ink-light);
font-weight: 600;
align-self: baseline;
padding-top: .15rem;
}
.hero .meta dd {
font-family: 'JetBrains Mono', ui-monospace, monospace;
font-size: .8rem;
margin: 0;
color: var(--ink);
overflow-wrap: anywhere;
word-break: break-word;
}
/* ---------- Sections ---------- */
section { margin-block: 3.5rem; }
.section-head {
margin-bottom: 1.5rem;
}
.section-head .label {
font-family: 'Source Serif 4', serif;
font-size: .68rem;
letter-spacing: .22em;
text-transform: uppercase;
color: var(--accent);
font-weight: 600;
margin-bottom: .35rem;
}
.section-head h2 {
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: 1.55rem;
line-height: 1.22;
letter-spacing: -0.006em;
margin: 0 0 .65rem 0;
color: var(--ink);
max-width: 36ch;
}
.section-head::after {
content: "";
display: block;
width: 2.5rem;
height: 1px;
background: var(--ink);
margin-top: .8rem;
}
h3 {
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: 1.12rem;
margin: 2.1rem 0 .65rem 0;
color: var(--ink);
}
p { margin: 0 0 .95em; }
p strong { font-weight: 600; color: var(--ink); }
em { font-style: italic; }
/* Inline code */
code {
font-family: 'JetBrains Mono', ui-monospace, monospace;
font-size: .82em;
background: var(--paper-bright);
padding: .08em .35em;
border: 1px solid var(--rule);
border-radius: 2px;
color: var(--accent-deep);
overflow-wrap: anywhere;
}
/* Block code */
pre {
font-family: 'JetBrains Mono', ui-monospace, monospace;
font-size: .76rem;
line-height: 1.55;
background: var(--paper-bright);
border: 1px solid var(--rule);
border-left: 2px solid var(--ink);
padding: .9rem 1.1rem;
margin: 1.25rem 0;
overflow-x: auto;
color: var(--ink-soft);
}
pre code { background: none; border: 0; padding: 0; color: inherit; }
/* Lists */
ul, ol { margin: 0 0 1em 1.3em; padding: 0; }
li { margin-bottom: .3em; }
ul li::marker { color: var(--accent); }
/* Blockquote — pull-quote / John conversation */
blockquote {
margin: 1.5rem 0;
padding: 0 0 0 1.5rem;
border-left: 2px solid var(--accent);
font-style: italic;
font-size: 1rem;
line-height: 1.55;
color: var(--ink-soft);
}
blockquote p:last-child { margin-bottom: 0; }
/* ---------- Tables ---------- */
.table-wrap {
margin: 1.4rem 0;
overflow-x: auto;
border-top: 1.5px solid var(--ink);
border-bottom: 1.5px solid var(--ink);
}
table {
width: 100%;
font-size: .9rem;
line-height: 1.45;
}
thead tr { border-bottom: 1px solid var(--ink); }
th {
text-align: left;
padding: .7rem .8rem;
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: .68rem;
letter-spacing: .14em;
text-transform: uppercase;
color: var(--ink);
vertical-align: bottom;
}
td {
padding: .65rem .8rem;
border-bottom: 1px solid var(--rule);
vertical-align: top;
color: var(--ink-soft);
}
td.num { font-family: 'JetBrains Mono', monospace; text-align: right; font-size: .85rem; color: var(--ink); }
td strong { color: var(--ink); }
td em { color: var(--ink-light); }
tbody tr:last-child td { border-bottom: 0; }
/* ---------- The four pillars (mental model diagram) ---------- */
.pillars {
margin: 1.5rem 0 1.75rem;
display: grid;
grid-template-columns: repeat(4, 1fr);
gap: 0;
border-top: 1.5px solid var(--ink);
border-bottom: 1.5px solid var(--ink);
background: var(--paper-bright);
}
.pillar {
padding: 1.1rem 1rem 1.2rem;
border-right: 1px solid var(--rule);
}
.pillar:last-child { border-right: 0; }
.pillar .stage {
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: .62rem;
letter-spacing: .18em;
text-transform: uppercase;
color: var(--ink-light);
margin-bottom: .45rem;
}
.pillar .name {
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: 1rem;
color: var(--ink);
margin-bottom: .3rem;
}
.pillar .qa {
font-style: italic;
font-size: .8rem;
line-height: 1.4;
color: var(--accent-deep);
margin-bottom: .7rem;
}
.pillar ul {
margin: 0;
padding: 0;
list-style: none;
font-size: .76rem;
line-height: 1.45;
color: var(--ink-soft);
}
.pillar ul li { padding-left: .85rem; position: relative; margin-bottom: .2rem; }
.pillar ul li::before { content: "—"; position: absolute; left: 0; color: var(--rule-strong); }
.pillar ul li code { font-size: .72rem; }
@media (max-width: 760px) {
.pillars { grid-template-columns: 1fr; }
.pillar { border-right: 0; border-bottom: 1px solid var(--rule); }
}
/* ---------- Group tree ---------- */
.tree {
margin: 1.5rem 0;
padding: 1rem 1.25rem;
background: var(--paper-bright);
border: 1px solid var(--rule);
border-left: 2px solid var(--ink);
font-family: 'JetBrains Mono', monospace;
font-size: .8rem;
line-height: 1.6;
color: var(--ink-soft);
}
.tree .root { color: var(--ink-light); }
.tree .inst { color: var(--ink); font-weight: 700; }
.tree .unit { color: var(--ink-soft); }
.tree .unit.john { color: var(--accent); font-weight: 700; }
.tree .annot {
color: var(--ink-light);
font-style: italic;
font-family: 'Source Serif 4', serif;
font-size: .76rem;
padding-left: .5rem;
}
.tree .annot.john { color: var(--accent); }
/* ---------- Scenario / timeline ---------- */
.scenario {
margin: 1.5rem 0;
padding: 1rem 1.25rem;
background: var(--paper-bright);
border: 1px solid var(--rule);
border-left: 2px solid var(--accent);
font-family: 'JetBrains Mono', monospace;
font-size: .78rem;
line-height: 1.6;
color: var(--ink-soft);
}
.scenario .stamp { color: var(--accent); font-weight: 700; }
.scenario .arrow { color: var(--rule-strong); }
.scenario .ok { color: var(--green); font-weight: 700; }
.scenario .stale { color: var(--accent); font-weight: 700; }
/* ---------- Big number cards ---------- */
.figures {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(160px, 1fr));
gap: .85rem;
margin: 1.5rem 0;
}
.figure {
padding: 1rem 1.1rem .95rem;
background: var(--paper-bright);
border: 1px solid var(--rule);
border-top: 2px solid var(--rule-strong);
}
.figure.legacy { border-top-color: var(--accent); }
.figure.modern { border-top-color: var(--green); }
.figure .big {
font-family: 'Source Serif 4', serif;
font-weight: 500;
font-size: 2.4rem;
line-height: 1;
letter-spacing: -.02em;
color: var(--ink);
}
.figure.legacy .big { color: var(--accent); }
.figure.modern .big { color: var(--green); }
.figure .label {
margin-top: .45rem;
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: .66rem;
letter-spacing: .14em;
text-transform: uppercase;
color: var(--ink-light);
}
.figure .desc {
margin-top: .35rem;
font-style: italic;
font-size: .82rem;
line-height: 1.4;
color: var(--ink-soft);
}
/* ---------- TL;DR ---------- */
.tldr {
margin: 1rem 0 0;
padding: 1.5rem 1.75rem;
background: var(--ink);
color: var(--paper-bright);
}
.tldr p {
margin: 0;
font-size: .98rem;
line-height: 1.6;
color: var(--paper-bright);
}
.tldr p strong {
color: #E5C9B5;
font-weight: 600;
}
/* ---------- Footer ---------- */
footer.colophon {
margin-top: 4rem;
padding-top: 1.1rem;
border-top: 1px solid var(--ink);
display: flex;
justify-content: space-between;
font-size: .68rem;
letter-spacing: .14em;
text-transform: uppercase;
color: var(--ink-light);
font-weight: 500;
}
/* Print */
@media print {
body { background: white; font-size: 11pt; }
body::before { display: none; }
.tldr { background: white; color: var(--ink); border: 1px solid var(--ink); }
.tldr p, .tldr p strong { color: var(--ink); }
.doc { width: auto; padding: 0 1.5cm; }
section, .pillars { break-inside: avoid; }
}
@media (max-width: 540px) {
body { font-size: 16px; }
.hero h1 { font-size: 1.65rem; }
.pillars { grid-template-columns: 1fr; }
}
/* ---------- Right-rail TOC (desktop) ---------- */
.toc {
position: fixed;
top: 50%;
right: 1.5rem;
transform: translateY(-50%);
width: 12.5rem;
max-height: calc(100vh - 4rem);
overflow-y: auto;
padding: 1rem 1.1rem;
background: var(--paper-bright);
border: 1px solid var(--rule);
border-left: 2px solid var(--accent);
z-index: 50;
font-size: .78rem;
line-height: 1.4;
}
.toc .toc-label {
font-family: 'Source Serif 4', serif;
font-size: .6rem;
letter-spacing: .2em;
text-transform: uppercase;
color: var(--ink-light);
font-weight: 600;
margin-bottom: .55rem;
padding-bottom: .45rem;
border-bottom: 1px solid var(--rule);
}
.toc ol {
list-style: none;
padding: 0;
margin: 0;
counter-reset: toc;
}
.toc ol li {
counter-increment: toc;
position: relative;
padding: .35rem 0 .35rem 1.5rem;
border-top: 1px solid var(--rule);
}
.toc ol li:first-child { border-top: 0; padding-top: .15rem; }
.toc ol li::before {
content: counter(toc, upper-roman) ".";
position: absolute;
left: 0;
top: .35rem;
font-family: 'Source Serif 4', serif;
font-weight: 600;
font-size: .7rem;
color: var(--accent);
}
.toc ol li:first-child::before { top: .15rem; }
.toc a {
color: var(--ink-soft);
text-decoration: none;
display: block;
}
.toc a:hover { color: var(--accent); }
/* Hide rail when viewport is too narrow to fit it next to the column */
@media (max-width: 1380px) {
.toc { display: none; }
}
/* ---------- Inline mini-TOC (mobile / narrow) ---------- */
.toc-inline {
display: none;
margin: 1.5rem 0 0;
padding: .9rem 1.1rem;
background: var(--paper-bright);
border: 1px solid var(--rule);
border-left: 2px solid var(--accent);
font-size: .82rem;
}
.toc-inline .toc-label {
font-family: 'Source Serif 4', serif;
font-size: .6rem;
letter-spacing: .2em;
text-transform: uppercase;
color: var(--ink-light);
font-weight: 600;
margin-bottom: .5rem;
}
.toc-inline ol {
list-style: none;
padding: 0;
margin: 0;
column-count: 2;
column-gap: 1rem;
}
.toc-inline ol li {
break-inside: avoid;
padding: .15rem 0;
}
.toc-inline a {
color: var(--ink-soft);
text-decoration: none;
}
.toc-inline a:hover { color: var(--accent); }
@media (max-width: 1380px) {
.toc-inline { display: block; }
}
@media (max-width: 480px) {
.toc-inline ol { column-count: 1; }
}
/* ---------- Back-to-top floater ---------- */
.top-link {
position: fixed;
right: 1.25rem;
bottom: 1.25rem;
z-index: 60;
display: inline-flex;
align-items: center;
gap: .35rem;
padding: .45rem .75rem .5rem;
background: var(--ink);
color: var(--paper-bright);
text-decoration: none;
font-family: 'Source Serif 4', serif;
font-size: .68rem;
letter-spacing: .14em;
text-transform: uppercase;
font-weight: 600;
border: 0;
box-shadow: 0 6px 18px -8px rgba(30,26,20,.45);
opacity: 0;
pointer-events: none;
transition: opacity .2s ease;
}
body.scrolled .top-link { opacity: 1; pointer-events: auto; }
.top-link:hover { background: var(--accent); color: var(--paper-bright); }
@media print { .top-link, .toc, .toc-inline { display: none !important; } }
</style>
</head>
<body id="top">
<!-- ─────────── Right-rail TOC (desktop ≥1380px) ─────────── -->
<nav class="toc" aria-label="Sections">
<div class="toc-label">On this page</div>
<ol>
<li><a href="#s1">Architecture & Standards</a></li>
<li><a href="#s2">DPI & Domain Experience</a></li>
<li><a href="#s3">Product / Solution Maturity</a></li>
<li><a href="#s4">Delivery & Support Model</a></li>
<li><a href="#s5">Pricing & Commercial</a></li>
<li><a href="#s6">Lock-in Risk Assessment</a></li>
<li><a href="#s7">Compliance & Risk</a></li>
</ol>
</nav>
<a href="#top" class="top-link" aria-label="Back to top">↑ Top</a>
<div class="doc">
<!-- ─────────── Masthead ─────────── -->
<header class="masthead">
<div>Vendor questionnaire response · UNCTAD eRegistrations</div>
<div class="right">2026-05-26</div>
</header>
<!-- ─────────── Hero ─────────── -->
<section class="hero">
<h1>UNCTAD eRegistrations —<br>Digital West Bank and Gaza</h1>
<p class="standfirst">Response to the World Bank vendor capability questionnaire (Report <code>P176090</code>, 2021), prepared by UNCTAD to promote the eRegistrations Digital Government Platform.</p>
<dl class="meta">
<dt>Respondent</dt><dd>UNCTAD, DIAE, Business Facilitation Programme</dd>
<dt>Solution</dt><dd>eRegistrations — UNCTAD Digital Government Platform</dd>
</dl>
<nav class="toc-inline" aria-label="Sections (mobile)">
<div class="toc-label">Contents</div>
<ol>
<li>I. <a href="#s1">Architecture & Standards</a></li>
<li>II. <a href="#s2">DPI & Domain Experience</a></li>
<li>III. <a href="#s3">Product / Solution Maturity</a></li>
<li>IV. <a href="#s4">Delivery & Support Model</a></li>
<li>V. <a href="#s5">Pricing & Commercial</a></li>
<li>VI. <a href="#s6">Lock-in Risk Assessment</a></li>
<li>VII. <a href="#s7">Compliance & Risk</a></li>
</ol>
</nav>
</section>
<!-- ═══════════════ §1 — Architecture & Standards ═══════════════ -->
<section aria-labelledby="s1">
<header class="section-head">
<div class="label">Section I</div>
<h2 id="s1">Architecture & Standards</h2>
</header>
<h3>Core technology stack</h3>
<p>Multi-stack microservices platform, all components open source or source-available:</p>
<ul>
<li><strong>BPA (Business Process Analyzer)</strong> — Java 22, Spring Boot 3.4 (back end); Angular 15 / TypeScript (front end). Service designers use it to model registrations, forms, roles, BOTs, and workflows without code. Process and decision models are authored in BPA using Camunda's BPMN-2.0 / DMN-1.3 model libraries, then deployed over REST to the standalone CIB7 workflow engine.</li>
<li><strong>DS (Display System)</strong> — Node.js / Express (back end) + Angular 17 / TypeScript 5.4 (front end). The citizen- and officer-facing UI.</li>
<li><strong>GDB (Generic Database Builder)</strong> — Python / Django + React. No-code register builder for foundational and sector databases.</li>
<li><strong>eregcms</strong> — Python / Django + AngularJS. CMS for portal content and catalog pages.</li>
<li><strong>Standalone workflow engine — <code>camunda-boot</code></strong> — Java 17/21, Spring Boot 3.4, <strong>CIB7 (CibSeven) 2.1.0</strong> — the community-maintained continuation of Camunda 7 BPM since Camunda's October-2025 EOL of Camunda 7 Community Edition. Runs BPMN 2.0 / DMN processes for advanced orchestration.</li>
<li><strong>Keycloak 26.4.5</strong> (Java 21) — Identity & Access Management; OpenID Connect, OAuth 2.0, SAML 2.0.</li>
<li><strong>RESTHeart 8.8.0</strong> (Java 21) — REST API layer over MongoDB.</li>
<li><strong>formio-server</strong> (Node.js 20 / Express) — Forms engine (Form.io-derived) backed by MongoDB.</li>
<li><strong>Integration layer — Mule ESB and Apache Camel</strong> — two interchangeable, open-source integration runtimes are supported and configured in production deployments. Country teams choose either (or run both side-by-side) depending on existing skill base and adapter availability: Mule ESB for visual flow design and the existing UNCTAD adapter library, Apache Camel for Spring-Boot-native enterprise integration with 300+ off-the-shelf components.</li>
<li><strong>ActiveMQ 5.17</strong> — JMS broker for asynchronous workflows.</li>
<li><strong>ClamAV</strong> — Malware scanning for uploaded documents.</li>
<li><strong>Graylog 4.3</strong> — Centralized log management and audit trail.</li>
</ul>
<h3>Database technologies used</h3>
<ul>
<li><strong>PostgreSQL</strong> — transactional data (BPA configuration, GDB registers, workflow state, audit metadata).</li>
<li><strong>MongoDB</strong> — document store for application files, form definitions, content, RESTHeart-served APIs.</li>
<li><strong>Elasticsearch</strong> — log indexing (via Graylog) and full-text search.</li>
<li><strong>ActiveMQ</strong> — message persistence (broker, not a database per se, but stateful).</li>
</ul>
<h3>Cloud platforms supported</h3>
<p>Cloud-agnostic. The platform runs anywhere Docker / Linux runs:</p>
<ul>
<li>On-premises (sovereign hosting on national data centres — current pattern for most country deployments).</li>
<li>Any public cloud: AWS, Azure, GCP, OVH, Oracle Cloud, Hetzner, regional providers.</li>
<li>Hybrid on-prem + cloud DR is supported.</li>
</ul>
<p>No proprietary cloud-service dependency. No serverless or vendor-specific managed services are required to run the platform.</p>
<h3>Containerization & orchestration</h3>
<ul>
<li><strong>Containerization</strong>: Docker (every service ships as an official <code>unctad/*</code> image).</li>
<li><strong>Orchestration today</strong>: Docker Compose with Portainer for instance management across DEV/TEST/PREVIEW/PRELIVE/LIVE environments.</li>
<li><strong>Kubernetes compatibility</strong>: images are 12-factor compliant and can be deployed on Kubernetes / OpenShift; the operational baseline used across current country deployments is Docker (Compose, and Swarm for newer installs).</li>
</ul>
<h3>CI/CD and DevOps practices</h3>
<ul>
<li><strong>Build pipelines</strong>: Jenkins (Jenkinsfile per repository), Bitbucket Pipelines, GitHub Actions for newer components.</li>
<li><strong>Image registry</strong>: private UNCTAD Docker registry (<code>unctad/*</code>).</li>
<li><strong>Per-instance pinning</strong>: each country instance is locked to specific image versions via <code>Conf-<ENV>/compose/<instance>/docker-compose.yml</code>, enabling reproducible, auditable deployments.</li>
<li><strong>DevSecOps</strong>: Gitleaks (secret scanning), SpotBugs + FindSecBugs and OWASP Dependency-Check (Java SAST/SCA), Bandit + pip-audit (Python), npm audit + eslint-plugin-security (JS/TS), Trivy (container scanning), Qodana Community.</li>
<li><strong>Pre-commit hooks</strong>: standardized across repos.</li>
<li><strong>Release strategy</strong>: trunk-based development on <code>develop</code>, with maintained <code>release/2.17</code> and <code>release/2.18</code> lines for stable production deployments.</li>
</ul>
<h3>API standards supported</h3>
<ul>
<li><strong>REST + JSON</strong> — primary, OpenAPI/Swagger documented.</li>
<li><strong>SOAP / XML</strong> — supported via Mule ESB or Apache Camel adapters for legacy integrations.</li>
<li><strong>JSON Schema</strong> — for form definitions and data contracts.</li>
<li><strong>BPMN 2.0 / DMN 1.3</strong> — process and decision modelling via CIB7 (CibSeven), the community continuation of Camunda 7.</li>
<li><strong>JMS / AMQP</strong> — asynchronous messaging via ActiveMQ.</li>
<li><strong>JWT / OIDC / OAuth 2.0 / SAML 2.0</strong> — authentication and authorization tokens via Keycloak.</li>
<li><strong>WebSocket</strong> — real-time updates for officer dashboards.</li>
</ul>
<p>GraphQL is not currently exposed by the platform; REST + OpenAPI is the recommended integration pattern.</p>
<h3>Architecture type</h3>
<p><strong>Selected: Microservices-based.</strong> <em>Alternatives presented in the form: Monolithic; Hybrid / mixed.</em></p>
<h3>Main architectural components</h3>
<p>The platform is organised around three citizen-/officer-facing application layers and a shared infrastructure layer.</p>
<ol>
<li><strong>Design layer — BPA (Business Process Analyzer)</strong>: service designers model each registration in a no-code interface — registrations, applicant files (data + documents + fees), roles (human or BOT), determinants, actions, certificates. Output is a configuration package consumed by the runtime.</li>
<li><strong>Runtime layer — DS (Display System)</strong>: citizen portal (apply, upload, pay, track) and officer back office (review, approve, send back, reject). Renders forms from Form.io JSON, executes workflow steps, manages the applicant file lifecycle.</li>
<li><strong>Data layer — GDB (Generic Database Builder)</strong>: no-code register builder for sector registries (companies, licences, properties, etc.), with REST APIs auto-generated per register for machine-to-machine integration.</li>
<li><strong>Integration layer — Mule ESB and/or Apache Camel + RESTHeart + CIB7</strong>: connects services with external systems (tax, ID, civil registry, payments) and orchestrates long-running workflows. Mule and Camel are both configured and supported as interchangeable adapter runtimes (country teams pick one or run both); RESTHeart provides MongoDB-backed REST APIs; CIB7 (CibSeven) runs BPMN 2.0 processes.</li>
<li><strong>Identity layer — Keycloak</strong>: OIDC/OAuth 2.0/SAML provider; integrates with national digital ID where available.</li>
<li><strong>Cross-cutting</strong>: ClamAV (document AV scanning), Graylog (logging/audit), ActiveMQ (messaging), Portainer (container ops).</li>
</ol>
<p>A typical country instance runs ~15–20 containers behind an NGINX/Traefik reverse proxy, with PostgreSQL and MongoDB as the persistence layer.</p>
<h3>Open-source components used</h3>
<p>The platform is itself open source / source-available. Notable third-party open-source components include:</p>
<ul>
<li><strong>Frameworks</strong>: Spring Boot, Angular, React, Django, Express, Form.io.</li>
<li><strong>Workflow / BPM</strong>: CIB7 (CibSeven) — community-maintained continuation of Camunda 7, fully BPMN 2.0 / DMN 1.3 compatible.</li>
<li><strong>Identity</strong>: Keycloak.</li>
<li><strong>Data</strong>: PostgreSQL, MongoDB, Elasticsearch, RESTHeart.</li>
<li><strong>Integration</strong>: Mule ESB (Community Edition) and Apache Camel — both supported as pluggable integration runtimes.</li>
<li><strong>Messaging</strong>: Apache ActiveMQ.</li>
<li><strong>Security</strong>: ClamAV, OWASP Dependency-Check, Gitleaks, Bandit, SpotBugs, FindSecBugs.</li>
<li><strong>Observability</strong>: Graylog, Prometheus, Grafana (via the dockprom stack).</li>
<li><strong>Container ops</strong>: Docker, Docker Compose, Portainer CE.</li>
</ul>
<h3>Proprietary components & IP</h3>
<p>The eRegistrations platform (BPA + Display System) and the Generic Database Builder (GDB) are <strong>UNCTAD intellectual property</strong>, licensed to government partners under formal bilateral "User Rights" agreements (see "Licensing terms" below). The supporting components (eregcms, the orchestration stack) are also UNCTAD work products distributed alongside the licensed components. It is not a commercial product, and it is not redistributed under an open-source licence. No third-party proprietary components are required to run the platform.</p>
<h3>Licensing terms for proprietary components / IP</h3>
<p>Provided under formal bilateral <strong>"User Rights" agreements</strong> between UNCTAD and the government partner — one for the eRegistrations system (BPA + Display System), one for GDB. The two agreements share the same structure. Standard terms (the Palestine User Rights agreements are representative):</p>
<ul>
<li><strong>Grant</strong>: right to use the Software in one live instance, plus additional instances for backup/disaster recovery, testing, and development; right to build and modify any number of online services or databases; right to modify the Software, add functionality, and merge copies.</li>
<li><strong>No licence fee</strong>: rights are granted at no monetary cost to the User.</li>
<li><strong>Source code</strong>: provided as part of the granted components, alongside technical and functional documentation.</li>
<li><strong>Non-exclusive, non-transferable</strong>: rights extend only to the named User and cannot be transferred to other entities without UNCTAD's prior written consent. Each government partner signs its own agreement directly with UNCTAD.</li>
<li><strong>Contribute-back under MIT</strong>: the User shares developments and source-code changes ("the Work") with UNCTAD's code repository under the MIT license at no cost; UNCTAD freely decides whether to integrate them upstream. In return, the User benefits from system updates from UNCTAD and other contributors.</li>
<li><strong>Maintenance</strong>: UNCTAD provides adaptive and corrective maintenance for <strong>24 months commencing at the end of the project</strong>.</li>
<li><strong>User-owned outputs</strong>: online services and databases built with the platform belong to the User; recorded information is the User's sole responsibility.</li>
<li><strong>IP</strong>: all rights not expressly granted remain UNCTAD's; the User cooperates with UNCTAD to defend its IP rights.</li>
<li><strong>Termination</strong>: UNCTAD may terminate the rights if the User breaches the agreement and fails to cure within 30 days of becoming aware of the breach.</li>
<li><strong>Disputes</strong>: amicable settlement first; failing that, UNCITRAL arbitration in Geneva, with UN privileges and immunities preserved throughout.</li>
<li><strong>Use of names/emblems</strong>: the UN name and emblem cannot be used by the User in connection with its business, and never for commercial purposes.</li>
</ul>
<p>Exact terms are confirmed per engagement; the intent of the model is <em>"free for the partner government to use and modify, source-available to the licensed partner, contributions returned to the upstream codebase under MIT, stewarded by UNCTAD."</em></p>
<h3>Supported open standards</h3>
<ul>
<li><strong>Identity</strong>: OpenID Connect, OAuth 2.0, SAML 2.0, JWT (via Keycloak).</li>
<li><strong>Process modelling</strong>: BPMN 2.0, DMN (via Camunda).</li>
<li><strong>Forms</strong>: Form.io JSON, JSON Schema.</li>
<li><strong>APIs</strong>: REST, OpenAPI 3 / Swagger.</li>
<li><strong>Interoperability layers</strong>: X-Road integration is supported (active in planning for Bhutan single-window).</li>
<li><strong>Document standards</strong>: PDF / PDF-A upload and storage, common image formats (PNG, JPEG). In-form e-signature capture (canvas-based, image-stamped onto rendered PDFs) ships with the platform via Form.io community-edition signature components. <strong>Cryptographically-strong, qualified electronic signatures are not bundled</strong> — they require integration with a national signing service. UNCTAD maintains a reference integration with <strong>SiGa</strong> (the Estonian government's open-source signing gateway, supporting BDOC / ASIC-E containers and Estonian ID-card / Mobile-ID), used in specific country deployments; comparable adapters for other national signing platforms can be built via the ESB layer (Mule or Apache Camel).</li>
<li><strong>Web standards</strong>: HTTPS/TLS 1.2+, HSTS, CSP, OAuth 2.0 PKCE.</li>
<li><strong>Encoding / data</strong>: UTF-8, ISO 8601 dates, ISO 3166 country codes, ISO 4217 currencies.</li>
</ul>
<p>HL7 FHIR is not currently used (eRegistrations is not a health platform). MOSIP integration has been studied but not deployed; integration is feasible via OIDC.</p>
<h3>Data interoperability approach</h3>
<p>Three complementary mechanisms:</p>
<ol>
<li><strong>Service-to-service via REST/JSON</strong>: every register in GDB and every service in BPA exposes documented REST endpoints. OpenAPI documentation is auto-generated.</li>
<li><strong>ESB-mediated integration via Mule or Apache Camel</strong>: where external systems use SOAP, legacy XML, fixed-width files, JMS, FTP, or country-specific protocols, Mule and/or Camel adapters translate to the platform's internal REST model. Both runtimes are configured and supported; the choice is made per country based on the local skill base and adapter inventory.</li>
<li><strong>Event-driven asynchronous integration via ActiveMQ</strong>: long-running workflows and outbound notifications are decoupled through queues.</li>
</ol>
<p>In addition, BOTs (Data BOTs) are first-class objects in BPA that let analysts wire external API calls into the workflow without code — for example, to validate a national ID number against the civil registry, or to push a granted licence to a downstream registry.</p>
<p>X-Road can be deployed alongside the platform when the country's interoperability framework is X-Road-based; eRegistrations services are exposed as X-Road subsystems.</p>
<h3>Security certifications held</h3>
<p>No commercial security certifications (ISO 27001, SOC 2) are held at platform level. As a UN agency, UNCTAD operates under the <strong>UN Personal Data Protection and Privacy Principles</strong> (2018) and the <strong>UN Information Security policies</strong> rather than commercial certification regimes.</p>
<p>For sovereign deployments (the typical model), the hosting country's own certification framework applies to the operated instance. The platform's component choices (Keycloak, PostgreSQL, MongoDB, etc.) are widely used in ISO 27001-certified environments.</p>
<h3>Encryption, access control, audit logging & security controls</h3>
<ul>
<li><strong>Encryption in transit</strong>: TLS 1.2+ everywhere (HTTPS, internal service mesh, database connections). Configurable to TLS 1.3.</li>
<li><strong>Encryption at rest</strong>: provided at the storage layer (PostgreSQL TDE / filesystem encryption / cloud-managed encryption, depending on hosting).</li>
<li><strong>Authentication</strong>: centralized via Keycloak (OIDC / OAuth 2.0 / SAML). MFA supported. Federation with national digital ID where available.</li>
<li><strong>Authorization</strong>: role-based access in BPA (roles per institution, per service, per status); attribute-based policies via Keycloak; row-level access in GDB.</li>
<li><strong>Audit logging</strong>: every application-file state change, role action, and administrative operation is logged with actor, timestamp, IP, and payload digest. Logs centralized in Graylog with retention policies configurable per instance.</li>
<li><strong>Document security</strong>: ClamAV scanning of every uploaded document; configurable file-type allow-list and size limits; signed-URL pattern for document retrieval.</li>
<li><strong>Secrets management</strong>:
<ul>
<li><strong>Docker Swarm secrets</strong> in newer country deployments. The Colombia LIVE stack (<code>Conf-LIVE/compose/colombia/docker-stack.yml</code>) runs in Docker Swarm mode with every sensitive value (database passwords, OAuth client secrets, MongoDB URIs, mail-server password, etc.) resolved through <code>DOCKER_SECRET:<NAME></code> placeholders or mounted at <code>/var/run/secrets/<name></code>.</li>
<li>The <strong><code>eregistrations-installer</code></strong> project (in active development) automates Docker-Swarm-mode installs: it generates random passwords for every component, populates them as Swarm secrets, and delivers the full credential set back to the operator as an <strong>age-encrypted vault</strong> (<code>credentials.age</code>, passphrase-protected).</li>
<li><strong>Legacy country deployments</strong> (installed before this generation) run Docker Compose with environment-variable injection — some externalized from the host shell, some inline. Migration of these instances to the Swarm + secrets pattern is in progress.</li>
</ul>
</li>
<li><strong>DevSecOps</strong>: Gitleaks pre-commit, SAST (SpotBugs + FindSecBugs / Bandit / eslint-plugin-security), SCA (OWASP Dependency-Check / pip-audit / npm audit), container scanning (Trivy), Qodana code quality.</li>
<li><strong>Network</strong>: reverse-proxy fronting (NGINX/Traefik), internal Docker networks, no direct database exposure to the internet.</li>
</ul>
<h3>Accessibility compliance (WCAG)</h3>
<p><strong>Selected: Partially compliant.</strong> <em>Alternatives presented in the form: Fully compliant; Not compliant; Unknown.</em></p>
<p>The DS citizen-facing UI follows WCAG 2.1 AA principles (semantic HTML, keyboard navigation, ARIA attributes, sufficient contrast, scalable typography, alt text on images). A formal third-party WCAG audit has not been completed at platform level. Country deployments have passed national accessibility reviews in several jurisdictions.</p>
</section>
<!-- ═══════════════ §2 — Previous Experience / DPI ═══════════════ -->
<section aria-labelledby="s2">
<header class="section-head">
<div class="label">Section II</div>
<h2 id="s2">Previous Experience / DPI & Domain Experience</h2>
</header>
<h3>Experience with digital building blocks / DPI components</h3>
<p><em>For example digital ID, civil registration, business registration, digital payments, or interoperability layers.</em></p>
<p>eRegistrations has been deployed across <strong>multiple regions</strong> (the Americas, Africa, the Middle East, and Asia) with <strong>dozens of country deployments</strong> spanning most categories of administrative registrations:</p>
<ul>
<li><strong>Business registration & single windows</strong> — Cuba (Ventanilla Única), Colombia, El Salvador, Mali (AMM), Benin (monentreprise.bj), Burundi, Lesotho, Kenya, Libya, Cameroon, Guatemala, Jamaica, Angola, Timor-Leste, Iraq, Jordan, Bhutan, and many others.</li>
<li><strong>Trade single windows</strong> — UNCTAD's Trade Portal product line, integrated with customs and logistics.</li>
<li><strong>Investment & licensing</strong> — sector-specific licences and foreign-investor authorizations modelled in several country instances.</li>
<li><strong>Civil-status linkages</strong> — integration with civil registries via Mule adapters where the country has a national registry (Lesotho, others).</li>
<li><strong>Digital ID integration</strong> — via Keycloak federation (OIDC/SAML) with national digital ID systems where they exist; otherwise eRegistrations issues its own credentials.</li>
<li><strong>Digital payments</strong> — flagship engagement with the <strong>Central Bank of Iraq (CBI)</strong>: integration with the <strong>National Switch</strong>, joint work with CBI on qualifying and onboarding payment providers, and an automated solution that distributes collected fees to the receiving agencies. Other country deployments connect to national payment gateways, mobile-money operators, and government treasury portals.</li>
<li><strong>Interoperability layers</strong> — X-Road (Bhutan), point-to-point REST/SOAP via Mule or Apache Camel everywhere else.</li>
<li><strong>Statistics & reporting</strong> — built-in statistics back end and Graylog-based audit dashboards.</li>
</ul>
<p>Functionally, the platform implements the <strong>"registration" archetype</strong> that underlies most government-to-citizen and government-to-business interactions — a single configurable foundation on which any number of administrative procedures (business, trade, investment, civil, sector-specific) can be modelled and operated.</p>
<h3>Experience integrating with legacy systems</h3>
<p>Country deployments have integrated with:</p>
<ul>
<li>Tax administration systems (SOAP, REST, file-based exchanges).</li>
<li>Civil registries (REST, SOAP, X-Road).</li>
<li>Customs systems (ASYCUDA, national equivalents).</li>
<li>Payment switches and treasury portals.</li>
<li>National ID and KYC systems.</li>
<li>Document management and archiving systems.</li>
<li>Email/SMS gateways.</li>
</ul>
<p>The integration workhorses are <strong>Mule ESB</strong> and <strong>Apache Camel</strong> — both supported and currently in production use across country deployments. A dedicated <code>mule-common</code> library encapsulates patterns shared across Mule-based country adapters; equivalent Spring-Boot starters bundle reusable Camel routes.</p>
<h3>Experience implementing data-exchange / interoperability platforms</h3>
<p><em>For example X-Road, MOSIP, OpenCRVS, or similar.</em></p>
<ul>
<li><strong>X-Road</strong>: in deployment for Bhutan (single-window scenario). eRegistrations services are exposed as X-Road subsystems; the platform integrates with X-Road security servers via REST.</li>
<li><strong>Custom interoperability layers</strong>: country-specific ESB layers (Mule-based or Camel-based) acting as the de-facto data-exchange layer between eRegistrations and national systems in deployments where no national interoperability platform exists.</li>
<li><strong>MOSIP</strong>: not currently deployed, but integration is technically feasible via OIDC federation (Keycloak) and REST APIs. Active interest from UNCTAD's eGovernment Section.</li>
<li><strong>OpenCRVS</strong>: not currently integrated. Possible via REST + a Mule or Camel adapter; civil-event triggers could feed into eRegistrations services as data BOTs.</li>
</ul>
<h3>Consent management & data-protection compliance</h3>
<p>The eRegistrations model operates under <strong>administrative law</strong>, not commercial consent-based data processing. Each service implements a <em>registration</em> — defined in the platform glossary as "an obligation defined by law" — for which the lawful basis is the <strong>regulation that mandates the registration</strong>, not consent. The GDPR concept of "consent management" therefore applies only in narrow scenarios (e.g. optional sharing with downstream registries beyond what the regulation itself requires); the platform does not ship a generic consent-management subsystem, because the registration's <em>scope</em>, defined by the regulation, is itself the legal frame for data collection.</p>
<p>Structural alignment with data-protection principles:</p>
<ul>
<li><strong>Purpose limitation by construction</strong>: each registration is anchored in a named national regulation that defines its purpose. The platform's data model cannot represent a registration without a defined scope.</li>
<li><strong>Data minimization by construction</strong>: the regulation defines the <em>scope</em> — the data, documents, and fees required. BPA only collects what the service designer has placed in the scope. The responsibility for matching that scope to the underlying regulation lies with the national service designer (typically an analyst from the relevant ministry).</li>
<li><strong>Trustworthy data sources (forward direction)</strong>: the platform is evolving toward the <strong>assertion / credential model</strong> described in the glossary's Advanced Glossary — authoritative registries (civil, tax, business, property) assert the attributes they own, and downstream services consume those assertions as trusted claims. This reframes data protection from <em>"minimize what the applicant must surrender"</em> to <em>"do not re-collect what an authoritative registry already holds."</em></li>
<li><strong>Accountability through audit</strong>: officer actions on applicant files are logged and centralized in Graylog under sovereign hosting.</li>
<li><strong>Sovereign hosting</strong>: under the typical deployment pattern, all personal data remains on the country's own infrastructure, subject only to the hosting country's data-protection law.</li>
<li><strong>Role-based access</strong>: officers see only the files and fields their role permits — enforced in BPA's role definitions.</li>
</ul>
<p>Areas governed by <strong>national law rather than by platform configuration</strong>:</p>
<ul>
<li><strong>Retention</strong> follows the country's archives law for administrative records; the platform does not impose a retention policy.</li>
<li><strong>Erasure / rectification</strong> of recorded data follows the same administrative-law procedures used for paper-based records (typically a formal request to the issuing institution), not a GDPR-style data-subject toggle. In a public registry, certain records (e.g. company incorporations) are by design non-erasable because the legal-person record was created under a regulation.</li>
<li><strong>Right to access one's own administrative file</strong> follows national right-to-administrative-information law where it exists; the platform makes such access technically feasible (data is structured and exportable) but the <em>legal entitlement</em> derives from national law.</li>
</ul>
<p>For the West Bank and Gaza deployment, the applicable framework would be the <strong>Palestinian Authority's data-protection and administrative-records law</strong> as it stands at deployment time. UNCTAD's deployment methodology includes a country-specific Data Protection Impact Assessment (DPIA) aligning each service design to that framework.</p>
</section>
<!-- ═══════════════ §3 — Product / Solution Maturity ═══════════════ -->
<section aria-labelledby="s3">
<header class="section-head">
<div class="label">Section III</div>
<h2 id="s3">Product / Solution Maturity</h2>
</header>
<h3>Primary product / platform</h3>
<p><strong>eRegistrations — UNCTAD Digital Government Platform</strong>, comprising:</p>
<ul>
<li>BPA (Business Process Analyzer) — design tool.</li>
<li>DS (Display System) — citizen and officer runtime.</li>
<li>GDB (Generic Database Builder) — no-code register builder.</li>
<li>Supporting services: Keycloak, CIB7 (Camunda 7 community continuation), RESTHeart, Mule ESB / Apache Camel, formio-server, eregcms, ClamAV, Graylog, ActiveMQ.</li>
</ul>
<p>Combined, these enable the design, deployment, operation and monitoring of any registration-based government service (business, trade, investment, licensing, civil events, permits, sector-specific authorisations).</p>
<h3>Product version and release date</h3>
<ul>
<li><strong>Current stable release</strong>: 2.18 line (BPA-backend 2.18.x, BPA-frontend 2.18.x, ds-backend 2.19.x, ds-frontend 2.18.x, GDB 2.18.x), continuously released through 2025–2026.</li>
<li><strong>Long-term support release</strong>: 2.17 (still receiving security patches for country instances pinned to it).</li>
<li><strong>Underlying components</strong>: Keycloak 26.4.5, <strong>CIB7 (CibSeven) 2.1.0</strong> as the platform's workflow engine (community-maintained continuation of Camunda 7 after Camunda's October-2025 EOL of the Community Edition), RESTHeart 8.8.0, Spring Boot 3.4. BPA-backend uses Camunda's BPMN-2.0 / DMN-1.3 model libraries as a REST client to the engine — there is no second embedded engine.</li>
</ul>
<p>UNCTAD operates a continuous-release model: image versions are pinned per country instance to ensure reproducibility, with bug-fix and security updates rolled out on a release/<version> cadence.</p>
<h3>Configurable product, customisable platform, or fully custom?</h3>
<p><strong>Selected: Platform requiring customization</strong> — no-code configuration is the dominant pattern, but country adapters and integrations are typically implemented per deployment. <em>Alternatives presented in the form: Configurable product; Fully custom-built; Hybrid / mixed.</em></p>
<p>Most country-specific work is done <strong>without code</strong>, in BPA and GDB, by national analysts trained by UNCTAD. Code-level customization is typically limited to country integration adapters (Mule ESB or Apache Camel), portal theming, and occasional new form components.</p>
<h3>Multi-tenancy</h3>
<p><strong>Selected: Yes</strong> (with caveats — see below). <em>Alternatives presented in the form: No; Unknown; Prefer not to disclose.</em></p>
<p>The platform supports multi-tenancy at the <strong>instance</strong> level — each country instance is fully isolated (its own URL, database, users, services). A single physical deployment can host multiple instances on the same infrastructure (UNCTAD does this for staging and shared-region clusters). Within a single instance, multi-institution segregation is enforced through the role/permission model rather than tenant isolation.</p>
<p>For a national deployment, the recommended pattern is <strong>one instance per country</strong>, with separate environments (DEV / TEST / PREVIEW / PRELIVE / LIVE).</p>
<h3>Low-bandwidth / offline / constrained connectivity</h3>
<p><strong>Selected: Yes</strong> (partially — online-first with low-bandwidth optimisations; full offline operation is not in scope). <em>Alternatives presented in the form: No; Unknown; Prefer not to disclose.</em></p>
<p>Features that help in constrained-connectivity contexts:</p>
<ul>
<li>Progressive loading, code-splitting, and aggressive client-side caching.</li>
<li>Tolerance for high-latency uplinks (asynchronous queueing of officer actions via ActiveMQ).</li>
<li>Lightweight, mobile-responsive DS UI.</li>
<li>On-prem deployment removes round-trips to external clouds.</li>
<li>Officers can draft work and resume; applicants can save and resume applications.</li>
<li>The platform itself runs on modest hardware (a country instance fits comfortably on a single mid-range server with redundancy).</li>
</ul>
<p>True <strong>offline-first</strong> operation (work without connectivity, sync later) is not currently a built-in capability of DS — it requires online connectivity at the moments of submission, payment, and decision.</p>
</section>
<!-- ═══════════════ §4 — Delivery & Support Model ═══════════════ -->
<section aria-labelledby="s4">
<header class="section-head">
<div class="label">Section IV</div>
<h2 id="s4">Delivery & Support Model</h2>
</header>
<h3>Project governance and reporting approach</h3>
<p>UNCTAD eRegistrations deployment methodology:</p>
<ul>
<li><strong>Steering committee</strong>: country counterpart institutions + UNCTAD project lead + funder representative. Meets monthly.</li>
<li><strong>Technical working group</strong>: country IT teams + UNCTAD eGovernment Section. Meets weekly during active design phases.</li>
<li><strong>Process working groups</strong>: per-registration, with subject-matter experts from the relevant ministry/agency. Convened as services are modelled.</li>
<li><strong>Reporting</strong>: monthly progress reports to steering committee; quarterly reports to the funding partner; project-management artefacts (work plan, risk log, change log) maintained throughout.</li>
<li><strong>Knowledge transfer</strong>: country analysts are trained to operate BPA and GDB themselves. Hand-over is incremental, not a "big bang" at the end.</li>
</ul>
<p>For a World Bank-financed engagement, reporting cadence and artefacts are aligned to the Bank's standard project-implementation framework.</p>
<h3>Estimated delivery timeline for comparable scope</h3>
<p>For a deployment comparable in scope to West Bank and Gaza (national single-window for business registration + several priority registrations + integrations with 3–5 national systems):</p>
<ul>
<li><strong>Inception, business-process diagnostic, and roadmap</strong>: 2–3 months.</li>
<li><strong>Platform installation and environments setup</strong>: 1–2 months (often in parallel with diagnostic).</li>
<li><strong>First wave of services (3–5 priority registrations)</strong>: 4–6 months from start.</li>
<li><strong>Integration with national systems (ID, tax, payments, civil registry)</strong>: 3–6 months (overlaps with service modelling).</li>
<li><strong>Pilot operation with limited applicant population</strong>: 2–3 months.</li>
<li><strong>Country-wide rollout</strong>: 2–4 months after pilot validation.</li>
</ul>
<p><strong>Total: 12–18 months</strong> from project start to country-wide live operation of the first wave of services. Subsequent waves of additional services are typically 3–6 months each.</p>
<h3>High-level milestone plan</h3>
<div class="table-wrap">
<table>
<thead>
<tr>
<th>Phase</th>
<th>Milestone</th>
<th class="num">Month</th>
</tr>
</thead>
<tbody>
<tr><td><strong>1. Inception</strong></td><td>Project kick-off, governance set up, baseline diagnostic begins</td><td class="num">M1</td></tr>
<tr><td><strong>2. Diagnostic</strong></td><td>Business-process diagnostic for priority services; legal/regulatory baseline</td><td class="num">M2–M3</td></tr>
<tr><td><strong>3. Roadmap</strong></td><td>Implementation roadmap and integration architecture approved</td><td class="num">M3</td></tr>
<tr><td><strong>4. Platform setup</strong></td><td>DEV, TEST, PREVIEW, PRELIVE, LIVE environments provisioned; Keycloak, GDB, BPA, DS operational</td><td class="num">M3–M4</td></tr>
<tr><td><strong>5. Service modelling (wave 1)</strong></td><td>Priority registrations designed in BPA; forms, roles, BOTs configured</td><td class="num">M4–M8</td></tr>
<tr><td><strong>6. Integrations</strong></td><td>ESB adapters (Mule or Apache Camel) for ID, tax, payments, civil registry implemented and tested</td><td class="num">M5–M9</td></tr>
<tr><td><strong>7. UAT</strong></td><td>User acceptance testing with line ministries and pilot applicants</td><td class="num">M9–M10</td></tr>
<tr><td><strong>8. Pilot</strong></td><td>Limited live operation with monitoring</td><td class="num">M10–M12</td></tr>
<tr><td><strong>9. Rollout</strong></td><td>Country-wide go-live; communication campaign</td><td class="num">M12–M14</td></tr>
<tr><td><strong>10. Stabilization & handover</strong></td><td>Operational handover to national team; knowledge transfer complete</td><td class="num">M14–M16</td></tr>
<tr><td><strong>11. Wave 2</strong></td><td>Additional registrations and registries onboarded</td><td class="num">M16+</td></tr>
</tbody>
</table>
</div>
<p>Phases overlap in practice; the table is indicative.</p>
<h3>SLA levels offered</h3>
<p>UNCTAD provides backbone maintenance of the upstream platform (releases, security patches, framework upgrades) as part of its eGovernment programme. Operational SLAs are agreed per country deployment and depend on whether the instance is UNCTAD-hosted or self-hosted.</p>
<p>Typical SLA framework for UNCTAD-hosted instances:</p>
<ul>
<li><strong>Uptime target</strong>: 99.0–99.5% monthly (24×7 availability, planned-maintenance windows excluded).</li>
<li><strong>Severity 1</strong> (production down / data integrity at risk): response within 1 business hour; mitigation in progress within 4 hours.</li>
<li><strong>Severity 2</strong> (major feature unavailable, workaround possible): response within 4 business hours; resolution target 2 business days.</li>
<li><strong>Severity 3</strong> (minor feature issue): response within 1 business day; resolution in next scheduled release.</li>
<li><strong>Severity 4</strong> (cosmetic, documentation): response within 2 business days; addressed at convenience.</li>
</ul>
<p>For self-hosted instances, UNCTAD provides upstream support (release engineering, advisory, patch backports), while operational SLAs are owned by the national operator.</p>
<h3>Escalation process for critical issues</h3>
<ul>
<li><strong>Level 1</strong>: country operations team / UNCTAD support desk via ticketing system (typically Jira Service Management).</li>
<li><strong>Level 2</strong>: UNCTAD eRegistrations technical team (back end, front end, integration, DevOps specialists).</li>
<li><strong>Level 3</strong>: UNCTAD eGovernment Section lead + product architects.</li>
<li><strong>Level 4</strong>: UNCTAD Division on Technology and Logistics management.</li>
</ul>
<p>For Severity 1 incidents: direct phone / instant-messaging channel to the on-call technical lead, in parallel with ticket creation. Post-incident review and root-cause analysis are mandatory.</p>
<h3>How change requests are handled</h3>
<ul>
<li><strong>No-code changes</strong> (new fields, new forms, new roles, determinant tweaks, BOT reconfiguration) are made directly in BPA / GDB by trained country analysts, with a versioned audit trail. These do not require a release cycle and can go live within hours after testing.</li>
<li><strong>Configuration changes</strong> (theming, translations, content) are managed through the relevant repos (eregcms, theme repos, translation system) with PR review.</li>
<li><strong>Code changes</strong> (new platform features, new integrations) follow the standard release process: backlog grooming, design, implementation on a feature branch, tests, code review, merge to <code>develop</code>, release-train cut to <code>release/<version></code>, deployment.</li>
<li><strong>Backports</strong>: bug-fixes on <code>develop</code> are evaluated for back-port to the active <code>release/<version></code> line and to specific country instances.</li>
<li><strong>Country-specific integrations</strong> are typically delivered as ESB projects (Mule or Apache Camel, depending on the local team's preference) and managed in country-specific integration repositories, keeping country logic out of the platform core.</li>
</ul>
<p>A formal change-control board governs platform-level changes; country governance decides on country-specific changes.</p>
</section>
<!-- ═══════════════ §5 — Pricing & Commercial ═══════════════ -->
<section aria-labelledby="s5">
<header class="section-head">
<div class="label">Section V</div>
<h2 id="s5">Pricing & Commercial</h2>
</header>
<p>The eRegistrations platform (BPA + Display System) and the Generic Database Builder (GDB) are <strong>UNCTAD-owned proprietary software</strong>, licensed to a government partner under formal bilateral <strong>"User Rights" agreements</strong> (one per system). Under these agreements:</p>
<ul>
<li><strong>No software licence fee is charged.</strong> The rights are granted at no monetary cost to the User.</li>
<li><strong>The User receives the system source code</strong> (alongside technical and functional documentation) and is granted the right to use, modify, add functionality, and merge copies — for one live instance, plus additional instances for backup/disaster recovery, testing and development.</li>
<li><strong>Rights are non-exclusive and non-transferable</strong>: they extend only to the named government User and cannot be passed to other entities, agencies, corporations, organizations, or persons without UNCTAD's prior written consent. Each prospective government partner signs its own User Rights agreement directly with UNCTAD.</li>
<li><strong>The User contributes its modifications back</strong> ("the Work") to UNCTAD's code repository under the MIT license at no cost. UNCTAD freely decides whether to integrate them upstream. In return, the User benefits from system updates from UNCTAD and from other contributors.</li>
<li><strong>Adaptive and corrective maintenance</strong> is provided by UNCTAD for a <strong>24-month period commencing at the end of the project</strong> (compatibility with OS/DB/network version changes; error correction).</li>
<li><strong>All online services and databases the User builds with the platform</strong> belong to the User. Information recorded in the system is the User's sole responsibility.</li>
<li><strong>All IP not expressly granted remains UNCTAD's.</strong> The UN name and emblem cannot be used by the User in connection with its business, and never for commercial purposes.</li>
<li><strong>Disputes</strong> are settled amicably; failing that, by UNCITRAL arbitration in Geneva. UN privileges and immunities are preserved.</li>
</ul>
<p>Project costs for a deployment therefore cover only:</p>
<ul>
<li>UNCTAD staff time and travel under the cooperation agreement (technical assistance, training, capacity building, installation).</li>
<li>Country-side personnel (analysts, integrators, operations team).</li>
<li>Infrastructure (hosting, network, monitoring) — on-prem or cloud, owned by the country.</li>
<li>Third-party integrations and adapters where required.</li>
<li>Any extended operational or maintenance support beyond the 24-month adaptive/corrective maintenance window.</li>
</ul>
<p>The funding model is typically a single-donor or multi-donor project funded by the country's development budget, a bilateral donor, or an IFI (World Bank, AfDB, IDB, etc.). UNCTAD does not charge licence or per-user fees and does not generate revenue from the software itself. Detailed budget proposals are prepared per engagement once scope is agreed.</p>
</section>
<!-- ═══════════════ §6 — Lock-in Risk Assessment ═══════════════ -->
<section aria-labelledby="s6">
<header class="section-head">
<div class="label">Section VI</div>
<h2 id="s6">Lock-in Risk Assessment</h2>
</header>
<h3>Vendor lock-in — proprietary licensing restrictions</h3>
<p>There are no commercial licence fees and no per-user fees. The platform is licensed to the government User under a bilateral "User Rights" agreement that allows the User to install, operate, modify, integrate, and build any number of online services or databases on top of it, at no monetary cost.</p>
<p>The restrictions defined by the User Rights agreement:</p>
<ul>
<li><strong>Non-transferable</strong>: rights extend only to the named User. The User cannot pass the software to other entities, agencies, corporations, organizations, or persons without UNCTAD's prior written consent. Each prospective government licensee negotiates its own agreement directly with UNCTAD.</li>
<li><strong>Contribute-back</strong>: source-code changes the User makes must be pushed back to UNCTAD's code repository under the MIT license. UNCTAD decides whether to integrate them upstream.</li>
<li><strong>UN name/emblem</strong>: cannot be used by the User in connection with its business, and never for commercial purposes.</li>
<li><strong>Termination for breach</strong>: UNCTAD may terminate the rights if the User breaches the agreement and does not cure within 30 days.</li>
</ul>
<p>The agreement does not impose ongoing royalties, per-seat fees, or commercial-redistribution carve-outs beyond the non-transferability clause.</p>
<h3>Data portability guarantees and export formats</h3>
<ul>
<li>Full database dumps (PostgreSQL <code>pg_dump</code>, MongoDB <code>mongodump</code>) are available to the country at any time and are owned by the country.</li>
<li>Application files are exportable as <strong>structured JSON</strong> (applicant data + metadata) plus the original uploaded <strong>documents</strong> (PDF, images, etc., in their original formats).</li>
<li>Form definitions are stored as <strong>Form.io JSON</strong>.</li>
<li>Workflow definitions are stored as <strong>BPMN 2.0 XML</strong> (Camunda standard).</li>
<li>Register schemas in GDB are exportable as JSON Schema; register data as CSV/JSON.</li>
<li>Audit logs are exportable from Graylog (JSON, CSV).</li>
<li>Configuration (BPA service definitions, role/registration models) is exportable as JSON.</li>
</ul>
<p>Nothing in the platform stores data in a proprietary or opaque format.</p>
<h3>Automated full-export capability</h3>
<p><strong>Selected: Yes</strong> — database-level dumps + JSON export tooling per service. <em>Alternatives presented in the form: No; Unknown; Prefer not to disclose.</em></p>
<p>Full-export tooling at the institutional level (which is what the question targets for lock-in assessment):</p>
<ol>
<li><strong>Infrastructure</strong>: <code>pg_dump</code> / <code>mongodump</code> cron jobs (standard in the reference deployment topology) produce complete database backups owned by the country.</li>
<li><strong>Service-level</strong>: BPA's service-export capability exports an entire service definition (forms, roles, BOTs, mappings, classifications, costs) as JSON for re-import, migration, or archival.</li>
</ol>
<p>The platform does <strong>not</strong> include an out-of-the-box applicant self-service "download my complete file" feature. Where a country wishes to offer this (e.g. as part of right-to-administrative-information compliance under national law), it can be added either as a <code>downloadFile</code> BOT step in the service flow (offering specific issued documents back to the applicant) or as a custom export endpoint in DS — neither is a default capability.</p>
<h3>Availability of alternative support providers</h3>
<p>Because the platform is built on widely-used open-source components (Spring Boot, Angular, React, Django, Keycloak, BPMN-2.0 engines, MongoDB, PostgreSQL), any team with skills in those technologies can operate and evolve a country instance once the User Rights agreement is in place and the source code has been transferred. Knowledge transfer to a country-based integrator team is built into UNCTAD's deployment methodology, so day-to-day operations and country evolutions do not need to depend on UNCTAD staff. UNCTAD itself remains the upstream maintainer.</p>
<h3>Community / ecosystem around the product</h3>
<ul>
<li><strong>Country implementation network</strong>: deployments across multiple regions, with in-country technical teams trained by UNCTAD on each engagement.</li>
<li><strong>UNCTAD eGovernment Section</strong>: full-time platform team (architects, back-end, front-end, integration, DevOps, support).</li>
<li><strong>Underlying open-source communities</strong>: Keycloak, Camunda, Spring, Angular, Django, Form.io, MongoDB, PostgreSQL — each with active global communities and abundant skills.</li>
<li><strong>Documentation and training</strong>: UNCTAD-maintained documentation; country-led training materials in multiple languages.</li>
<li><strong>Knowledge bases</strong>: NOVA (internal UNCTAD knowledge base for the platform) and per-country runbooks.</li>
</ul>
<h3>Dependency on vendor-specific cloud / infrastructure</h3>
<p><strong>None.</strong> The platform is fully cloud-agnostic. It runs on any Linux infrastructure (bare-metal, VMs, on-prem hypervisor, public cloud, private cloud) that can run Docker. No managed cloud service (e.g., AWS RDS, Azure-specific identity, GCP-specific storage) is required. Sovereign on-premise deployment is the typical pattern, precisely to avoid this kind of dependency.</p>
<h3>Product lock-in — open vs proprietary data formats</h3>
<p>All data formats are open standards: JSON, JSON Schema, BPMN 2.0 XML, OpenAPI 3, PDF, PNG/JPEG, CSV, UTF-8 text. No proprietary binary formats. Database schemas are open and documented (PostgreSQL, MongoDB).</p>
<h3>API openness and documentation quality</h3>
<ul>
<li>All REST APIs are documented via <strong>OpenAPI 3 / Swagger</strong> and exposed under each service's <code>/swagger-ui</code> endpoint.</li>
<li>GDB registers auto-publish an OpenAPI spec per register.</li>
<li>Internal architecture documents and per-service ADRs are maintained.</li>
<li>Country-specific documentation is generated automatically from BPA service definitions (UNCTAD provides <code>service-documentation</code> tooling that produces citizen-facing HTML manuals and analyst Excel reports from any service).</li>
<li>API versioning follows semantic versioning.</li>
</ul>
<h3>Transition support and typical transition timeline</h3>
<p>A national operator can take over operations independently of UNCTAD at any time, because:</p>
<ul>
<li>Source code is held by the country.</li>
<li>Operations rely on standard open-source tooling (Docker, Linux, PostgreSQL, MongoDB).</li>
<li>Data is in open formats with documented schemas.</li>
<li>Service-documentation tooling auto-generates citizen-facing HTML user manuals and analyst Excel reports directly from any BPA service definition; per-country operational runbooks live alongside the deployment configuration. Documentation transfers to the User as part of the handover.</li>
</ul>
<p>Typical transition timeline (UNCTAD → national operator or alternative integrator): <strong>3–6 months</strong> of shadowing and progressive handover, depending on the level of in-house capability at the start.</p>
<p>Transition to a <strong>different platform entirely</strong> is a much larger undertaking (data migration, workflow re-modelling) and is uncommon, since the platform itself adapts to country needs through configuration rather than requiring replacement.</p>
<h3>Component replaceability</h3>
<p>High. Because the architecture is microservices with clear boundaries:</p>
<ul>
<li><strong>Identity (Keycloak)</strong> can be replaced by any OIDC-compatible IdP.</li>
<li><strong>Workflow engine (CIB7 / CibSeven)</strong> can be replaced by any BPMN 2.0-compatible engine (Camunda 8, Flowable, jBPM, Activiti…) since processes are stored in standard BPMN 2.0 XML.</li>
<li><strong>Forms engine (formio-server)</strong> can be replaced by another JSON-Schema-based engine (re-mapping required).</li>
<li><strong>Message broker (ActiveMQ)</strong> can be replaced by any JMS-compatible broker, or by Kafka with adapter changes.</li>
<li><strong>Log aggregator (Graylog)</strong> can be replaced by ELK, Loki, Splunk, etc.</li>
<li><strong>Databases (PostgreSQL, MongoDB)</strong> — PostgreSQL is locked in by SQL features used; MongoDB could be replaced by any document store, but with significant rewrite.</li>
</ul>
<p>The most foundational pieces (BPA, DS, GDB) are platform-defining and would not be "replaced" — they <em>are</em> the platform. Replacement of those would mean replacing the product.</p>
<h3>Source-code availability / escrow</h3>
<p><strong>Selected: Direct source-code access</strong> (granted to government partners as part of the User Rights agreement). <em>Alternatives presented in the form: Source-code escrow only; Limited / conditional access; No source-code access.</em></p>
<p>The full source code of the platform components is made available to the government partner's technical team as one of the components named in the User Rights agreement (alongside the running software and technical/functional documentation). Access is granted via Git (Bitbucket / GitHub) at engagement start. The government partner can mirror the repositories on its own infrastructure to ensure long-term availability of the code it has been licensed. Modifications made by the country team must be pushed to UNCTAD's code repository under the MIT license; UNCTAD freely decides whether to integrate them upstream.</p>
<h3>Contractual exit / transition terms</h3>
<ul>
<li><strong>No licence fee → no licence-fee penalties on exit.</strong></li>
<li>The User retains full ownership of the data, of the online services and databases it built with the platform, and of the local copy of the source code it holds nationally.</li>
<li>The User Rights agreement provides for <strong>termination by UNCTAD if the User breaches the agreement and fails to cure within 30 days of becoming aware of the breach</strong>. No symmetric financial exit penalty is defined for either party.</li>
<li>A formal handover plan typically accompanies any exit, covering operations, documentation, integration, and knowledge transfer.</li>
</ul>
<p>There is no commercial exit leverage. Note, however, that the User Rights agreement is <strong>non-transferable</strong>: the User cannot hand the licensed software off to another government, vendor, or integrator without UNCTAD's prior written consent — a successor would need to enter into its own User Rights agreement with UNCTAD.</p>
</section>
<!-- ═══════════════ §7 — Compliance & Risk ═══════════════ -->
<section aria-labelledby="s7">
<header class="section-head">
<div class="label">Section VII</div>
<h2 id="s7">Compliance & Risk</h2>
</header>
<h3>Business continuity and disaster recovery plans</h3>
<p>Pattern for production deployments:</p>
<ul>
<li><strong>Backups</strong>: nightly full + frequent incremental of PostgreSQL and MongoDB; hourly snapshots of document storage. Backups stored off-site / in a separate availability zone.</li>
<li><strong>High availability</strong>: active-active or active-passive for stateless services (BPA back end, DS back end, RESTHeart, formio-server, Keycloak); clustered PostgreSQL (streaming replication) and MongoDB (replica set).</li>
<li><strong>DR site</strong>: warm-standby in a geographically separated facility, with periodic restore drills.</li>
<li><strong>Runbooks</strong>: documented incident-response and recovery procedures, maintained per country instance.</li>
<li><strong>Monitoring</strong>: Prometheus + Grafana + Graylog; 24×7 alerting where the SLA requires it.</li>
</ul>
<p>Specific BC/DR posture is sized to the criticality and budget of each country deployment.</p>
<h3>Recovery Point Objective (RPO) target</h3>
<ul>
<li><strong>Recommended/typical</strong>: 1 hour (achieved via hourly transaction-log shipping and incremental backups).</li>
<li><strong>Aggressive (premium configurations)</strong>: ≤ 15 minutes (synchronous database replication, continuous archiving).</li>
<li><strong>Minimum acceptable</strong>: 24 hours (nightly backup only, for low-criticality deployments).</li>
</ul>
<h3>Recovery Time Objective (RTO) target</h3>
<ul>
<li><strong>Recommended/typical</strong>: 4 hours (warm-standby with documented failover procedure).</li>
<li><strong>Aggressive (premium configurations)</strong>: ≤ 1 hour (hot-standby with automated failover).</li>
<li><strong>Minimum acceptable</strong>: 24 hours (cold-standby).</li>
</ul>
<p>Both RPO and RTO can be tuned per country based on criticality, budget, and operational maturity; the target tier is agreed at design time as part of the deployment plan.</p>
<h3>Ongoing legal proceedings, sanctions, or debarment actions</h3>
<p>None. UNCTAD is an organ of the United Nations and is not subject to commercial debarment or sanctions regimes; no ongoing legal proceedings affect the eRegistrations platform or its delivery.</p>
<h3>Additional notes, assumptions, and source links</h3>
<ul>
<li>UNCTAD Digital Government platform: <a href="https://digitalgovernment.world/">https://digitalgovernment.world/</a></li>
<li>Trade Information Portals: <a href="https://digitalgovernment.world/trade-information-portals/">https://digitalgovernment.world/trade-information-portals/</a></li>
<li>World Bank report referenced in this engagement: <code>P176090</code>, <em>Digital West Bank and Gaza</em>, 2021.</li>
<li>The eRegistrations programme is run by UNCTAD's eGovernment Section under its Division on Technology and Logistics.</li>
<li>All version numbers and component choices in this response reflect the platform as of 2026-05-26. Specific country deployments may pin earlier release lines (e.g. 2.17) for operational stability.</li>
<li>Architecture and security claims are grounded in the open repositories maintained by UNCTAD (BPA-backend, BPA-frontend, ds-backend, ds-frontend, GDB, Camunda, Keycloak, RESTHeart, formio-server, eregcms, Mule ESB and Apache Camel integration projects, eregistrations deployment configuration). Source-code access for verification purposes can be granted to the World Bank technical reviewers on request.</li>
</ul>
</section>
<footer class="colophon">
<div>UNCTAD eRegistrations · Vendor questionnaire response</div>
<div>2026-05-26</div>
</footer>
</div>
<script>
// Show "↑ Top" only after the user has scrolled past the hero.
(function () {
var threshold = 600;
var ticking = false;
function update() {
document.body.classList.toggle('scrolled', window.scrollY > threshold);
ticking = false;
}
window.addEventListener('scroll', function () {
if (!ticking) {
window.requestAnimationFrame(update);
ticking = true;
}
}, { passive: true });
})();
</script>
</body>
</html>