# The tender Write the tender in markdown, in this order, with these headings. This is the form `site/js/modules/tender-core.js` draws. It runs to about 1,700 to 2,400 words without the optional annexe. Write it in the issuer's voice: where a question said "your organisation", the tender says "the issuer". Name no product or company and mention no precedent. Replace each word in capitals or braces. Text that is not in capitals is fixed: copy it exactly. ## The form ``` # Tender: SHORT NAME OF THE USE CASE ISSUER NAME, or: Issued by a TYPE OF ORGANISATION Issued DATE. Bids due DATE. Security level: LEVEL NAME. ## 1. Summary ONE PARAGRAPH ## 2. Background and problem PARAGRAPHS ## 3. Scope DESCRIPTION, then the parts as a list ## 4. Functional requirements PRIORITY KEY, then a heading and a table for each lot ## 5. Non-functional requirements SECURITY SENTENCE, then a table ## 6. How the work may be delivered ## 7. Who owns what ## 8. Compliance checks ## 9. What stays with the issuer ## 10. Pilot first ## 11. Conventional alternative ## 12. How bids are evaluated ## 13. Schedule ## 14. About the issuer ## 15. How to respond --- FOOT LINES ``` Each section is described below. The two spaces at the end of the meta lines make line breaks in markdown. ## 1. Summary One paragraph: `ISSUER invites bids for SHORT NAME IN LOWER CASE. FIRST SENTENCE OF THE DESCRIPTION. A pilot comes first, and full rollout follows only if it passes the tests in section 10. The first-year budget is BUDGET. A conventional alternative is welcome (section 11).` Leave out the budget sentence if the person left the budget out. ISSUER is the organisation name, or `The issuer` in the anonymised copy. When the decision brief said no, use something simpler, or not much to change, add a second paragraph, `The issuer's decision brief did not recommend this tender.` followed by the brief's first reason in the issuer's voice, without the quoted answers and with a full stop. The brief is advice, not a gate: a tender can be built after any answer that names a problem, and after a no it says so here. ## 2. Background and problem Three kinds of paragraph, in this order, each only if you have it: the problems the person named (`The issuer has named this problem: ...` or `these problems: ...`, in the issuer's voice, joined with semicolons); the person's own words (`In its own words: "..."`, cut to about 420 characters; left out of the anonymised copy); and the need and readiness reasons from the decision brief for this use case, rewritten in the issuer's voice and without the scores in brackets. Leave out the brief's first reason, the one about the rule. If you have none of these, write `The issuer has described this problem in its assessment and wants a supplier to address it.` ## 3. Scope The use case's description from USE-CASES.md, in the issuer's voice. Then, when the use case needs more than one part, `The solution is made up of the lots in section 4.` With one part only, `The solution is expected to include:` and the part as a list, with the first letter capitalised. Never use the examples. ## 4. Functional requirements First the key, copied exactly: > MUST: a bid that does not meet it is set aside. SHOULD: it counts in the scoring, and a bid is not set aside without it. Each row gives the minimum a bid should meet. Then one lot for each part of the solution, as set out below. Under each lot, a table with the columns `Requirement`, `Priority`, `Minimum to meet`. One row for each answer in TENDER-QUESTIONS.md that the person gave: - Requirement: if the question has a statement (the three "how it will be used" questions and the six about the organisation), the statement with the answer in place of the braces, for example `Data is kept: Inside the EU or EEA.` Otherwise the question and the answer together: the question in the issuer's voice, then the label of the answer. Several labels are joined with semicolons. - Priority: MUST only where the question is a hard gate and the answer asks for something. Otherwise SHOULD. - Minimum: the sentence for the question's requirement type in TENDER-QUESTIONS.md. Leave out any row the person asked you to leave out, and any row about a sensitive question in the anonymised copy. ### The lots A lot is one required part of the use case. Take the parts from `requiredComponents` in `data/ngo-use-case-catalogue.json`, once each, in that order, and number them from 1. Name each lot with the part's plain name from `data/component-labels.json`, written in the issuer's voice with a capital first letter: `### Lot N: NAME`. Put a requirement's row under the lot it belongs to, with this rule (the words are in the `lots` entry of `data/tender-questions.json`): - A question whose id is in `lots.fixed` goes under General. - Otherwise take the question's id, its brief section and its text, in lower case. Read the rules in `lots.rules` in order. The first rule whose `match` pattern is found in that text and that names a kind of part the use case has decides the lot. A kind of part is a list of part ids in `lots.classes`; the lot is the first part of the use case in that list. - If no rule decides it, use the part whose id or plain name shares the most words with the question, comparing the first five letters of each word of four letters or more and skipping the stems in `lots.stopWords`. If no part shares a word, it goes under General. - General comes last, as `### General`, and only when it has rows. A lot with no row says: `No separate requirement. The bid says what it delivers and how it is tested.` ## 5. Non-functional requirements One sentence for the security level, then if it was raised: `Raised one level because the use handles sensitive personal data.` Then a table with `Requirement` and `Priority`. The level comes from the use case's security level in TENDER-QUESTIONS.md. It is raised from Standard to Higher when the use case handles significant personal data. The sentences: - Standard: Standard security. The system holds ordinary organisational and programme data. - Higher: Higher security. The system holds personal or financial data about the people the issuer serves. - Critical: Critical security. The data could put people at risk if it were exposed or changed. Rows, each as `LABEL: TEXT`. A row is MUST at the levels shown. - Encryption: Data is encrypted in transit and at rest. Minimum: Encryption in transit and at rest. MUST at: Critical. - Sign-in: {signin} Minimum: The bid names the sign-in method and who it covers. MUST at: Critical. - Activity records: Every change is logged with its author and time. Logs are kept for at least 7 years. Minimum: Logs kept for 7 years and exportable. MUST at: no level. - Availability: The system is available {uptime}. Minimum: The bid states the availability it commits to. MUST at: no level. - Breach notice: {breach} Minimum: A written breach notice process. MUST at: Critical. - Security assurance: The supplier holds a recognised information security certification, or has had an independent audit in the last two years. Minimum: A recognised information security certification or an independent audit in the last two years. MUST at: Critical. Fill the placeholders from the level: - Standard: signin = A second sign-in step is offered to administrators. uptime = 99.0% (about 88 hours down a year) breach = The supplier tells the issuer of a data breach within 72 hours. - Higher: signin = A second sign-in step is required for administrators. uptime = 99.5% (about 44 hours down a year) breach = The supplier tells the issuer of a data breach within 72 hours. - Critical: signin = A second sign-in step is required for every user who can see personal data. uptime = 99.9% (about 9 hours down a year) breach = The supplier tells the issuer of a data breach within 24 hours. ## 6. How the work may be delivered `A bid says which of these ways it uses.` Then a list, each item as `**NAME.** TEXT`. The person chooses which of the three to accept (all three by default, at least one). List only the ones accepted, in this order: - One provider for everything. One provider holds the contract. - A lead provider with named specialists. The lead holds the contract and answers for the whole bid. - Several providers and one integrator. The issuer contracts the providers, and one integrator who joins them up. ## 7. Who owns what `A bid names one party for each item, or it is incomplete.` Then a table with the columns `Item`, `What the named party does`, `Named in the bid`. The last column is left empty for the bidder. One row for each item that applies. An item applies when it is marked always, or when a required part of the use case falls under one of the supplier families named for it (the `family` of each part is in `data/component-labels.json`), or when the use case has one of the parts named for it: - Integration: Joins the lots and answers for faults across them. Always asked. - Sanctions screening: Screens every party to a payment. Asked when a required part falls under: payments. Also asked when the use case has one of these parts: kyc-platform, background-check-integration, compliance-rules-engine. - Key custody and recovery: Holds the keys, runs recovery, states who may sign. Asked when a required part falls under: payments, custody. - Data-protection impact assessment: Carries out the assessment before personal data is processed. Asked when a required part falls under: identity, data platform. - Personal data off the ledger: Keeps personal data off the ledger, where it can be erased. Asked when a required part falls under: identity, data platform. - Audit log: Keeps and exports the log of every action. Always asked. - Posting to the finance system: Sends each transaction to the accounting system. Asked when a required part falls under: payments, custody. ## 8. Compliance checks First `This section flags questions to check. It is not legal advice.` copied exactly. This section flags questions to check. It gives no legal advice, so do not add any. Then `A legally required licence makes the statement MUST.` and a table with the columns `Lot`, `Rule that may apply`, `Who is obliged`, `What the bid states`, `Priority`. One row for each lot and each kind of rule in the lists below for that part, using `Lot N` in the first column. A lot with no kind of rule has no row. With no rows at all, write `No lot here has a specific rule flagged. The bid says if it knows of one.` in place of the table. Priority is MUST for a kind of rule marked licence below, unless the part is one of these soft parts: donation-platform, payment-collection, crypto-acceptance, payment-gateway. Everything else is SHOULD. A licence the law requires is a hard gate. Where the same kind of rule applies to a second or later lot, write `As lot {n}.` (with the first lot's number) in the rule column and `The same.` in the obliged column and, unless the person changed it, in the proof column. The kinds of rule: - bridge (licence). Rule: EU crypto-asset rules (MiCA): exchanging crypto-assets for money, or moving them for others, needs authorisation. Donation tools: not settled. Obliged: The provider. Bid states: Authorisation number or written reasoning for exemption, the regulator and the countries. - custody (licence). Rule: EU crypto-asset rules (MiCA): holding assets or keys for others needs authorisation. Key share or recovery rights: not settled. Obliged: The provider holding keys. Bid states: Who holds key shares, recovery and signing rights, with a written argument for the bid's own regulatory status. - stablecoin (licence). Rule: EU crypto-asset rules (MiCA): only a bank or e-money firm with a filed white paper may offer an e-money token. Third-country issuers: not verified. Obliged: The token issuer. Bid states: The issuer's authorisation, and whether it can freeze tokens. - travel (question to check). Rule: EU transfer rules (Regulation 2023/1113): sender and receiver details are collected, and self-hosted addresses verified from 1,000 euros. Obliged: The provider. Bid states: The travel-rule tool and how self-hosted addresses are verified. - sanctions (question to check). Rule: EU sanctions rules bind an EU-registered NGO. An intermediary does not pass the duty on. Obliged: The issuer and the provider. Bid states: Parties and lists screened, how often, and what happens on a match. - payout (licence). Rule: National rules in each country of payout, including the mobile money licence. Obliged: The payout partner. Bid states: Per country and route: whether it is lawful, and the licence holder. - data (question to check). Rule: EU data protection law: wallet addresses can be personal data, and moving personal data out of the EU needs a legal mechanism. Obliged: The issuer as controller, the provider as processor. Bid states: The mechanism for each data transfer, and how data is kept to a minimum. - dpia (question to check). Rule: GDPR Article 35: an impact assessment is needed before processing that may put people at high risk, such as sensitive data about many people or about vulnerable people. Obliged: The issuer as controller. The provider helps. Bid states: How the provider will help, and the risks it already knows of. - biometric (question to check). Rule: GDPR Article 9: biometric data used to identify a person is a special category and needs a specific legal basis and extra safeguards. Obliged: The issuer as controller, the provider as processor. Bid states: Whether biometric data is collected, where templates are stored, and how a person can enrol without it. - children (question to check). Rule: GDPR Articles 7 and 8: consent must be freely given and easy to withdraw. Children's data needs particular care, and the age of consent differs by country. Obliged: The issuer as controller. Bid states: How consent is recorded, who may give it for a child, and what happens for a child who cannot. - minimisation (question to check). Rule: GDPR Article 5: collect only the personal data the purpose needs. Obliged: The issuer and the provider. Bid states: Each field collected and why, and what is not collected. - erasure (question to check). Rule: GDPR Articles 5 and 17: keep personal data no longer than needed and erase it on request. A ledger that only adds records cannot erase, so keep personal data off it (EDPB Guidelines 02/2025). Obliged: The provider designs it. The issuer sets retention. Bid states: What is held off the ledger and what is on it, how long each is kept, and how erasure works. - controller (question to check). Rule: GDPR Articles 26 and 28: say in writing who is controller, joint controller or processor. Obliged: The issuer and the provider. Bid states: The role of each party for each kind of data, and the agreement. - records (question to check). Rule: Accounting: a crypto-asset that gives no claim on another party is stock or an intangible asset, not cash. Redeemable stablecoins: not settled. Obliged: The issuer sets policy. The provider supplies data. Bid states: An audit log export and transaction data ready for accounting. The kinds of rule for each part (a part not listed has none): - on-ramp: bridge - off-ramp: bridge, payout - on-off-ramp: bridge, payout - crypto-acceptance: bridge - donation-platform: bridge - payment-collection: bridge - wallet-infra: custody - beneficiary-wallet: custody - vendor-wallet: custody - staff-wallet: custody - mobile-wallet: custody - multi-sig: custody - multi-sig-treasury: custody - stablecoin: stablecoin - stablecoin-treasury: custody, stablecoin - voucher-token: stablecoin - token-engine: stablecoin - payment-rails: travel - payment-gateway: travel - farmer-payment-rail: travel, payout - compliance-screening: sanctions - sanctions-screening: sanctions - kyc-platform: sanctions - compliance-rules-engine: sanctions - background-check-integration: sanctions - redemption-ux: payout - merchant-network: payout - vendor-network: payout - insurance-payout: payout - consent-management: data - consent-engine: data - privacy-tech: data - anonymisation-tools: data - encryption-privacy: data - data-protection-layer: data - data-sovereignty-layer: data - right-to-be-forgotten: data - biometric-capture: data - data-layer: data - safeguarding-records: data - registry-platform: data - shared-registry: data - audit-mechanism: records - audit-trail: records - decision-audit-trail: records - reporting-module: records - reporting-automation: records - donor-reporting: records - accounting-integration: records - reconciliation-engine: records - reconciliation-ledger: records - disbursement-record: records - fund-tracking: records - record-keeping-platform: records - timestamping-service: records - evidence-platform: records The kinds of rule for personal data go with the supplier family of a lot, not with a single part. For each family below, put the rules on the first lot whose part is in that family, once each (skip a kind already used on an earlier lot): - identity: dpia, biometric, children, minimisation, erasure, controller - data platform: dpia, children, minimisation, erasure, controller These rules are SHOULD, except at the highest security level (tier C), where they are MUST: dpia, biometric, children, minimisation, erasure, controller. They are never licence gates. When any of them is MUST, add `The personal data lines are MUST too.` after the introduction. ### Country rules After the table, `### Country rules` and a list with one line for each country the issuer works in, in the order given and once each. Match the name without regard to capital letters. Each line is the text below followed by `Check this with your own legal adviser.`. A country that is not listed gets `{country}: no rule has been checked for this country.` with the country's name. With more than 6 such countries, write one line, `{countries}: no rule has been checked for these countries.`, with the names. With no countries, leave the heading out. Points marked not verified stay marked. - Kenya: a virtual asset law has applied since 4 November 2025, with licences from the Central Bank (wallets, payment processors, stablecoin issuers) and the Capital Markets Authority (exchanges). Self-custody and currency exchange: not verified. - Uganda: no virtual asset law and no licensed provider. The central bank governor said in February 2026 that these assets are not legal tender and not prohibited. Currency exchange rules: not verified. - Somalia: the Central Bank said in June 2024 that these assets are not legal tender and no provider is licensed. Exchange rules: not verified. - Ethiopia: a National Bank notice of 23 July 2026 prohibits using, transferring or exchanging virtual assets unless authorised. Using these assets there may not be permitted. Known from law-firm commentary only (not verified). - Bangladesh: Bangladesh Bank bars dealing in virtual assets, including by banks and mobile financial services, and repeated this in July 2026. Using these assets there may not be permitted. Rules for NGO donations: not verified. ## 9. What stays with the issuer `Whoever wins, these stay with the issuer.` Then the list, copied as it is: - Sanctions compliance, including partners and agents, even when a provider runs the screening. - The wallet policy: who signs, allowed addresses, approval limits and key recovery. - Checks on donors and partners, proof that beneficiaries exist, and the records. - Legal advice for each country. - Data controller duties and accounting policy. ## 10. Pilot first In this order. First, `The first thing a supplier delivers is a pilot of {months} months, limited to one location or one group of users that the issuer names at contract. The issuer decides on full rollout only after the pilot report. Bidders price the pilot and the rollout separately.` with the months from the level: Standard 3, Higher 4, Critical 6. If the brief gave conditions: `Before the pilot starts, the issuer is working on these conditions:` and the conditions as a list. If the brief said yes, once these change: `Before the pilot starts, the issuer will have:` and one line for each readiness area the brief named as a gap, `{area}, brought up to what the pilot needs.` with AREA in place of the braces, and no score. Then `The pilot must prove the following.` and a table with `Test` and `What must be true`: - Must pass: The measures of success agreed before the pilot reach their targets. - Must pass: Most pilot users choose the new way over the old one. Adoption is at least 60%. - Must pass: The system stays up at the agreed level and has no unresolved critical fault. - Must pass: Each hand-off works end to end, between providers as well as inside one. - Should pass: Rules for who owns, sees and deletes the data are written down and in use. - Should pass: The plan for when something fails has been rehearsed at least once. - Should pass: The issuer can see how the system is performing without asking the supplier. - Welcome: Security measures beyond the minimum are in place. - Welcome: Everyone who uses the system in the pilot has been trained. Then: `Full rollout is considered when all four must-pass and all three should-pass tests are met. A missed should-pass test extends the pilot. The last two tests are welcome, not required.` Then `Acceptance tests for the pilot report:` and the list: - For each test above, the pilot report gives the evidence that it was met, with figures and how they were measured. - The pilot report lists what must carry into full rollout: unresolved issues, partial results, untested areas, open concerns and timeline limits. ## 11. Conventional alternative Bidders may propose a conventional approach that meets the same requirements. If you do, say why it is better for the issuer: cost, risk, time to value or fit with existing systems. A conventional bid is scored on the same criteria and still includes the pilot. ## 12. How bids are evaluated `Each criterion is scored from 0 to 5 and multiplied by its weight.` and, only at the Critical level, `Risk carries more weight because the data could put people at risk.` Then a table with `Criterion`, `Weight`, `What the bid shows`. The weights add up to 100 and depend on the level: - Technical fit: How the solution meets the requirements, shown in a demonstration. Weights: Standard 30%, Higher 30%, Critical 25%. - Delivery plan and team: The named team, the pilot plan and two references from similar organisations. Weights: Standard 20%, Higher 20%, Critical 20%. - Cost: Three-year cost with every fee listed. Pilot and rollout priced separately. Weights: Standard 20%, Higher 15%, Critical 10%. - Risk and exit: Supplier stability, lock-in, exit terms and insurance that fits the data held. Weights: Standard 15%, Higher 20%, Critical 30%. - Integration and liability across lots: Who joins the lots, who answers for faults across them, and how hand-offs are tested. Weights: Standard 15%, Higher 15%, Critical 15%. ## 13. Schedule A table with `Step` and `Date`. Dates are counted in days from the issue date, and the person may change them: - Tender issued: 0 days after issue - Bidders' questions close: 14 days after issue - Bids due: 28 days after issue - Shortlist and demonstrations: 42 days after issue - Decision: 56 days after issue - Pilot starts: 84 days after issue - Pilot report and rollout decision: the pilot length after the pilot starts Write dates as 16 October 2026. ## 14. About the issuer The name and type, then `Size: SIZE.`, `Works in COUNTRIES.` and `Sector: SECTOR.` for what you hold. In the anonymised copy: `The issuer is {article} {type}.` with the type, and no name. ## 15. How to respond `Send your bid by {bids} to {contact}. Questions go to the same contact by {questions}. Answers are shared with all bidders without naming who asked.` BIDS, QUESTIONS and CONTACT are the dates and the contact. Without a contact: `the contact named in the notice` In the anonymised copy add: `Contact details are given to registered bidders through the tender board.` Then the way to bid. If the integrator model is accepted, `A bid may cover one lot, several lots or all of them.` otherwise `A bid covers every lot.` If the lead model is accepted, add `Providers may bid together under one named lead.` Then `For each lot, mark how the bid covers it. Name any partner.` and a table with the columns `Lot`, `Off the shelf`, `Through a named partner`, `Built for this bid`, one row for each lot (not General), written as `Lot N: NAME`, with the other columns empty for the bidder. Last, `A bid includes:` and the list: - A one-page summary. - Your answer to each requirement above, saying how you meet the minimum. - A pilot plan with the site, the team, the tests and the dates. - Prices for the pilot and for rollout, listed separately. - Two references from similar organisations, with a contact for each. ## The foot After a line `---`: `Prepared with IRF v2, in association with the Nordic Blockchain Association` and the issue date, each on its own line with two trailing spaces. ## The review Before you give the person the tender, go through every row of sections 4 and 5 and every row of the compliance table in section 8. Ask whether the row is wrong, whether it should change, and whether it is a hard gate or a nice-to-have. Show the minimum and let the person confirm or change it. Ask which of the three ways of delivering the work the issuer accepts. Record changes and write the final text from them. ## The anonymised copy Offer a copy with no organisation name, no contact name or address, no phone number, no link, no sensitive answer and no row about a sensitive question. Where the name stood, write `the issuer`. ## The optional annexe If the person asks for the formal procurement annexe, use the `annexe` entry in `data/tender-questions.json` and add it after the foot under its own title.