Frequently asked questions
General
What is escrow?
Software escrow is an agreement between three parties: the supplier of software, the user of that software and a neutral custodian, the escrow agent. That custodian keeps the source code (and any data) in storage as a safety net. If the supplier falls away through bankruptcy or ceasing the service, the user can request the deposit and keep using the software or have it maintained.
Who is escrow intended for?
Escrow is relevant for any organisation that is critically dependent on software from an external supplier. Think of custom software, business-critical SaaS services or cloud platforms whose continuity cannot be guaranteed without additional arrangements. Both the user (beneficiary) and the supplier of the software can take the initiative for an escrow agreement.
What is the difference between Software Escrow, SaaS Escrow and CloudSecure?
With Software Escrow, Softcrow takes the source code of the software into escrow. With SaaS Escrow it also takes the customer data and a description of the SaaS infrastructure. CloudSecure® goes further: there Softcrow safeguards, through a specific legal structure, that the entire cloud service keeps running, even if the supplier goes bankrupt, as long as beneficiaries keep paying their licence.
View the overview of our services →
What does software escrow cost?
Softcrow uses a simple pricing structure with one-off start-up costs and annual costs. A verification audit is optional and is invoiced separately. Key verification is free of charge.
Can I arrange escrow online?
No, and that is a deliberate choice. Every situation is different. Which release conditions are appropriate? Is it SaaS or on-premise software? Have additional measures already been taken? Is it a tripartite agreement between one supplier and one beneficiary, or is a collective agreement more suitable with several beneficiaries joining? And if it is collective: can the deposit be released to all beneficiaries at once, or are beneficiary-specific deposits needed? Those questions deserve personal attention.
Softcrow prefers to help you directly, so that the agreement fits your specific situation.
That does not mean it takes long. Over the past 30 years our standard agreement has passed dozens of lawyers and is immediately sufficient for all parties in most cases. The tailoring, in particular the release conditions, is included in the one-off start-up costs. From the first conversation to signing is usually a matter of days.
Get in touch → About the agreement →
Who pays the cost of an escrow?
The cost split is determined in consultation between supplier and beneficiary. Any split is possible, from fully borne by the supplier to fully borne by the beneficiary, or a combination of both.
What happens if Softcrow itself goes bankrupt?
The online escrow services are provided by Softcrow Trusted Electronic Services B.V. That company itself uses a CloudSecure arrangement, working together with Stichting Softcrow Continuïteit Services as custodian of the entire service environment.
Should Softcrow Trusted Electronic Services B.V. ever go bankrupt, the Stichting can, on the basis of that arrangement, take over and continue the entire service. Customers retain access to their dashboard, deposits stay intact, and ongoing agreements remain in force.
Softcrow thereby applies the same principle to itself as to its customers: continuity through escrow, secured in the structure, not just promised in a contract.
Some escrow providers are part of a broader IT services package. Does that make a difference?
Yes. Escrow requires neutrality, of the escrow agent, but also of the business activity within which the escrow agent operates. A provider that combines escrow with security consulting, technical audits and/or platform services by definition also has other interests. That need not be a problem, but it is something to be aware of when choosing.
Softcrow only does escrow. No additional services, no platform integrations, no other commercial agenda. Escrow as the goal, not as a front door. That is a matter of principle, and has been for more than 35 years.
Some escrow providers use a civil-law notary as custodian. Is that not the most reliable option?
In the Netherlands a civil-law notary has a statutorily anchored position of neutrality, with external supervision through the KNB and the Bureau Financieel Toezicht. That sounds solid, and for paper deeds it is. But a notary is not set up to store digital deposits.
In practice that means: anyone choosing a notary as escrow agent almost always runs into a collaboration between that notary and a technical partner that supplies the infrastructure. That technical partner then has full access to the contents of the deposit. The notary is legally responsible, but the deposit itself is not held by them and its confidentiality depends on the arrangements with that third party.
Zero-knowledge storage goes a step further: the architecture makes access impossible, not merely undesirable. Softcrow never receives the encryption key. The deposit is encrypted by the supplier before delivery. Even if Softcrow wanted to view what is stored, that is technically not possible, not because it is forbidden, but because the architecture rules it out.
That is the difference between trust enforced by professional rules, and trust enforced by the technology.
Is Softcrow ISO 27001 certified?
Our storage infrastructure runs in ISO 27001 certified data centres within the EU. Softcrow as an organisation is going through the process for its own ISO 27001 certification; we will complete that after the delivery of our renewed platform.
ISO 27001 is valuable. It forces an organisation into a structured information security management system, in which information security becomes a fixed part of the processes. We value that and have organised ourselves accordingly.
At the same time, it is worth knowing what the certification does and does not entail. ISO 27001 tests whether an organisation systematically identifies, weighs and treats its risks according to its own risk policy. It does not prescribe a specific way of working, nor a protection level. For ISO the rule is: describe what you do, and do what you have described. If it is laid down that the deposits are stored in the same folder as the encryption keys, then that is ‘well’ arranged according to the standard.
For escrow, those contents are of particular importance. The decisive security for us lies in the architecture: zero-knowledge and end-to-end encryption. The supplier encrypts client-side and we never receive the key. As a result, even Softcrow cannot read the contents of a deposit. No key, no access. The information we store for our customers therefore poses no security risk either: even in the event of a data breach on our side, the deposits remain encrypted and the contents unreadable.
Zero-knowledge and a certificate complement each other: first the architecture, with which the security policy is anchored in the IT itself, then the certificate as a stamp that the processes are in order. The first ensures that the contents of your deposit are accessible to no one, not even us. For protecting what you deposit, that weighs most heavily for us.
Does escrow also work for AI applications?
Yes. AI software is software: the same escrow principles apply. An AI application usually consists of source code, model weights, training configurations and system prompts. All those components together form a deposit: encryptable, deliverable and able to be stored at Softcrow in the same way as traditional software.
If you run a model locally and enrich it with your own data, for example by fine-tuning it or by attaching your own knowledge base (vector store), then the trained weights and datasets that result are your property. It is precisely that enrichment with your own data that is often the most valuable and proprietary part of an AI application, and you can deposit it just as well as the source code.
Softcrow stores the deposit zero-knowledge: the contents are no concern of ours, whether it is traditional code or AI components.
What escrow does not solve: the dependence on external AI platforms such as OpenAI, Anthropic or Google. If you use their APIs, you have no access to the underlying model weights, and what you do not own, you cannot deposit. That applies to everyone, including providers that sell “AI escrow” as a separate product. What they store in that case are configurations and prompts, not models.
For the dependence on external AI platforms, escrow is not the answer, but the risks are not unmanageable. Prompts, configurations and working methods that are documented and managed outside the platform are transferable to another platform. That requires no special tooling, only discipline.
If you build or purchase your own AI software whose source code and model components rest with the supplier, and that software is hosted internally, then escrow is exactly what it is intended for.
So far we deposit AI components within an existing Software Escrow, without a separate AI agreement. If a specific situation calls for it, we draw up a separate agreement for it.
For the beneficiary
Should I arrange escrow before having software developed?
Experience shows that the moment at which escrow comes up strongly determines how smoothly the process runs. The earlier the topic is raised, preferably before the parties have already made other arrangements about the software, the easier the alignment with the escrow agreement.
If you have software developed to order and want to make escrow part of it, raise it in advance during the negotiation of the development contract, and have the escrow agreement co-signed at the moment the software contract is signed. If you only knock on the supplier’s door about it afterwards, existing contractual relationships complicate the acceptance process and you negotiate from a weaker position. That is no reason not to do it, but it is a reason to raise it early.
What exactly does Softcrow store in a deposit?
That depends on the service. With Software Escrow, Softcrow takes the source code of the software into escrow. With SaaS Escrow also the customer data. With CloudSecure a legal structure is additionally set up that safeguards the continuity of the entire cloud service. All deposits are encrypted by the supplier itself. Softcrow has no access to the contents.
How does zero-knowledge storage work?
The supplier encrypts the deposit itself, before delivery, with an encryption key that they manage. Softcrow never receives that key. That means that even Softcrow has no access to the contents of the deposit. The deposit is end-to-end encrypted (E2EE): from supplier to beneficiary, without any intermediate party being able to view the contents. “Zero-knowledge” refers to the position of Softcrow as custodian: no key, no access. The encryption key is made available to the beneficiary by the supplier outside Softcrow. Softcrow thereby positions itself explicitly as a zero-knowledge software escrow agent.
Zero-knowledge also means that Softcrow cannot verify what is in a deposit, or whether the supplied metadata, such as the checksum of the encryption key, is correct. Softcrow stores only what the supplier has delivered, and transmits it unchanged. Responsibility for a correct and complete delivery lies with the supplier.
What happens if the supplier goes bankrupt?
If the supplier goes bankrupt, the beneficiary can request release of the deposit. The release conditions are laid down in the escrow agreement. Because the deposit falls legally outside the bankruptcy estate, it is immediately clear during the settlement that it does not form part of the estate, so that the release simply goes ahead. Softcrow coordinates the release process.
That is fundamentally different from the position without escrow. Without a sound arrangement, on bankruptcy the beneficiary is left only with an unsecured claim, at the back of the queue, after the trustee, the Tax Authority and preferential creditors. Payment is exceptional in practice.
What is your legal position if the supplier goes bankrupt?
Without escrow you have no access to the source code. You also have no right to use it. The source code is the intellectual property of the supplier and falls into the bankruptcy estate on bankruptcy.
Arranging maintenance yourself through former employees of the supplier offers no way out. Anyone using the source code without a right infringes that intellectual property. You then have to deal with the trustee.
As a creditor you are moreover in a weak position. A claim for release or continuation is an unsecured claim. It comes at the back of the queue, after the estate debts and the preferential creditors such as the Tax Authority. In practice, due to a lack of assets, almost nothing of that remains.
With escrow it is different. The escrow agreement lays down in advance that the deposit is released to the beneficiary in the agreed situations. Your licence also changes: from a runtime licence (running only) to a full development licence (maintaining and developing it further yourself). The agreement moreover lays down that on bankruptcy the deposit automatically passes into safekeeping. That way it stays outside the bankruptcy estate.
It is important, though, that you arrange escrow in good time, well before a bankruptcy is in sight. An arrangement made shortly before a bankruptcy can be reversed by the trustee (the actio pauliana). So arrange escrow in good time, as a fixed part of your IT risk management.
How do I keep a grip on my own data with a SaaS service?
With a SaaS service, both the software and your data run at the supplier. That makes you more dependent than with software you run locally: the back-ups sit within the supplier’s domain and are not accessible to you. In a multi-tenant environment it is often unclear how your data is separated from that of other users. Moreover, few SaaS environments are built so that you can export your data in usable form at any time (export-first).
SaaS Escrow provides an independent counterweight to this. The supplier deposits both the source code and your data, automatically updated via incremental snapshots, at Softcrow as a neutral third party. That way there is always an up-to-date, independent copy outside the supplier.
That copy reaches you under the agreed release conditions, for example if the supplier falls away, with how you get your own data back cleanly laid down in advance. So it is not an export button for daily use, but a continuity safeguard that reduces your dependence on the supplier.
How do I, as beneficiary, request release?
If the release conditions in your escrow agreement have been met, you contact Softcrow and submit a release request. Softcrow checks whether the conditions have indeed been fulfilled and then releases the deposit. You can then download the deposit and unpack it with the encryption key you received from the supplier, after which the readable files are available for further development or maintenance of the software.
Which release conditions are usual?
Release conditions are laid down in the escrow agreement and can differ per situation. Usual ones are: bankruptcy of the supplier, situations where the continuity of the software is not safeguarded, ceasing the service, or the structural failure to meet maintenance or support obligations. Softcrow helps in formulating conditions that fit your situation. What is appropriate depends on the nature of the software and the beneficiary’s dependence.
What if a release request is disputed?
Not every release request is uncontested. With a declared bankruptcy the situation is legally settled. With other conditions the supplier can dispute the request. In that case Softcrow takes no position on who is right: Softcrow takes a neutral position as escrow agent and does not release as long as the situation is not clear.
The best protection is preventive: release conditions that refer to objectively verifiable facts leave no room for discussion. The more concrete the wording, the more smoothly the release process runs if it ever comes to that.
Release conditions: how do you formulate them well? →
What is a key verification?
Because all deposits at Softcrow are encrypted, as a beneficiary you want to be able to check from time to time whether the key you hold actually fits the deposit, without waiting until it ever comes to that. Key verification offers that possibility and is free of charge.
It is a mathematical check. With an upload, the supplier also includes a checksum (a check value) of the key. You calculate that same checksum over the key you received from the supplier when joining the deposit, and compare the two. If they match, you have the correct key with 99.99% certainty.
In the Dashboard we make a tool available for this with which you easily calculate such a check value and make the comparison.
Key verification says nothing about the completeness or usability of what is in the deposit, only that the key is correct. For a substantive assessment a verification audit is needed.
What is a verification audit?
In a verification audit, the supplier builds a working environment on the basis of the deposit and a step-by-step compilation manual supplied in advance. An independent NOREA Register IT auditor oversees (virtually) and assesses whether the build proceeds in accordance with the supplied description. A beneficiary can request it, but a supplier can also initiate it themselves. Afterwards all parties involved receive a verification report. Softcrow advises having this carried out at least every one or two years.
The outcome depends on the completeness and quality of the supplier’s delivery. Changes that take place after the audit fall outside its scope. That is why we advise repeating the audit periodically, certainly after major updates.
Does an escrow help in complying with DORA, NIS2 or ISO 22301?
Yes. Escrow is a demonstrable measure for several compliance frameworks. DORA obliges financial entities to manage ICT third-party risks; an escrow is a direct implementation of the exit strategy requirements in articles 28 and 30. NIS2 requires continuity measures for critical ICT dependencies. ISO 22301 (business continuity management) names software dependencies as a critical risk; escrow is a standard BCM measure. In addition, escrow is relevant for ISO 27001 (supplier risk), the EU Cyber Resilience Act and the BIO (Baseline Informatiebeveiliging Overheid).
Escrow and compliance: per framework →
For the supplier
Do you also offer data escrow?
Yes. We offer data escrow via a separate data escrow agreement with a data deposit linked to it. It is therefore truly ‘data only’: in the data deposit Softcrow stores solely the customer data of the supplier, usually updated daily via automated snapshots.
Worth knowing, though: data without the accompanying software often has limited value. Many customers therefore combine the data deposit with a source code deposit, as part of a SaaS Escrow or CloudSecure arrangement. Anyone who only wants to secure the data can turn to the standalone data escrow agreement.
Do you also offer knowledge escrow or IP escrow?
What other providers call knowledge escrow or IP escrow, Softcrow arranges via an additional deposit within an existing Software Escrow, SaaS Escrow or CloudSecure agreement. That deposit can contain, besides source code, other information as well: infrastructure descriptions, technical documentation or other business-sensitive information relevant for continuity on release.
It is not a separate service, but part of a broader escrow scheme. In practice the demand for it is limited: most continuity questions are covered by the source code and possibly the data.
How do I deliver a deposit?
Softcrow offers several deposit options: manually via the web uploader in the dashboard, automated via the Softcrow CLI (available for Windows, macOS, Linux and Unix), or incrementally via snapshots for data deposits. Which method fits best depends on the type and amount of data, the environment and the working method of your organisation.
What is a deposit specification?
The deposit specification is the only readable information about what is in the encrypted deposit. It is metadata that you, as supplier, draw up with each delivery: which source code is included, which version number, which additional files and which tools or environments are needed to build the software. The specification is visible in the Softcrow Dashboard for both you and the beneficiary. A clear, complete specification is essential: it is the only way the beneficiary can assess whether the deposit is complete and relevant.
Is an escrow deposit at Softcrow resistant to quantum computers?
Yes. The Softcrow CLI uses solely AES-256 symmetric encryption, driven by 256-bit hardware-level entropy. AES-256 still offers 128 bits of effective security even after quantum halving, computationally uncrackable. Because the CLI uses no asymmetric encryption, the deposit is moreover immune to Shor’s algorithm, which can fully break traditional public/private key pairs.
In combination with our zero-knowledge architecture (Softcrow never sees, transmits or stores the encryption key), a deposit is cryptographically locked, regardless of how the technology develops.
This applies provided that the correct encryption and a sufficiently strong encryption key are used; those two are decisive. Via the Softcrow CLI both are secured. With the web uploader, the supplier makes those choices themselves and also bears the responsibility for them; we can then only advise on what is best.
More about security by design →
Some escrow providers use asymmetric encryption. Is that not safer?
No, for escrow the opposite is true. Asymmetric encryption (RSA, ECC) contains mathematical problems that a quantum computer with Shor’s algorithm can solve exponentially fast. RSA-2048 and similar keys can thereby be fully broken once a sufficiently powerful quantum computer is available.
Softcrow uses no asymmetric encryption. The Softcrow CLI encrypts solely with AES-256, a symmetric algorithm for which no comparable quantum vulnerability exists. Grover’s algorithm can halve the effective key strength from 256 to 128 bits, but 128 bits remains computationally uncrackable.
Asymmetric encryption is often used in other systems for key exchange, to transfer the symmetric key securely. Softcrow does not need that step: the encryption key is created by the supplier themselves and made available to the beneficiary outside Softcrow. There is no digital key exchange, and therefore no asymmetric vulnerability either.
More about security by design →
Why is zero-knowledge storage important?
You send a back-up out the door end-to-end encrypted. For your source code at an escrow agent the same reasoning applies: what is in it is too important to leave readable at an external party.
Source code is the intellectual property of the supplier, and often its most valuable asset. If an escrow agent had access to the contents of the deposit, a risk of conflicts of interest or unwanted access arises. Zero-knowledge storage rules that out entirely.
Because Softcrow never receives the encryption key, it is technically impossible for Softcrow to view the contents of a deposit. The supplier therefore has to fully trust that their source code stays confidential, not because Softcrow promises it, but because the architecture enforces it. That is the difference between trusting words and trusting technology.
Is zero-knowledge at Softcrow the same as a zero-knowledge proof (ZKP)?
No, those are two different things. A zero-knowledge proof (ZKP) is a cryptographic protocol with which one party proves to another that it knows or possesses something, without disclosing that information itself. It is a mathematical proof technique, known from blockchain and authentication applications among others.
At Softcrow, zero-knowledge means something different: it describes our position as custodian. The supplier encrypts the deposit client-side and the encryption key never reaches Softcrow. As a result we have zero knowledge of the contents, no key, no access. That is a property of the storage architecture, not a mathematical proof.
So Softcrow uses no zero-knowledge proofs, and for escrow that is not needed either. The confidentiality stems from the simple fact that we do not have the key, not from a cryptographic protocol. The same outcome, no access to your data, by a simpler route.
How can I be sure the CLI does not send my encryption key to Softcrow?
Softcrow’s zero-knowledge architecture is not just a promise: it is anchored in the design of the CLI. The CLI sends the encryption key to Softcrow at no point: not during the creation of a deposit, not during the upload, not afterwards.
Suppliers who want to inspect the source code to verify this themselves can make an appointment at our office for that.
Do I have to use the Softcrow CLI for compression and encryption?
No. The CLI is recommended because it demonstrably encrypts quantum-safely and produces the AES256-ZIP format that is directly compatible with the Softcrow infrastructure, but using it is not mandatory. Via the web uploader you can deliver a deposit that you have assembled and encrypted with your own tooling.
Some suppliers deliberately opt for that freedom, to keep full control over the encryption process, or because they prefer to carry out the steps themselves without the involvement of Softcrow’s tooling. That is a legitimate choice.
Softcrow advises on what is technically safe and compatible, but has no interest in which software or method you use. Responsibility for the encryption quality and the compatibility on release lies with the supplier. The condition is that the deposit specification clearly describes which compression and encryption method has been applied, so that the beneficiary knows how to open the deposit on release.
What does it mean that Softcrow is sovereign?
Sovereignty means that our storage infrastructure falls entirely outside US jurisdiction. The data is 100% within the EU, under EU law, and through our organisational structure is not subject to the US CLOUD Act or USA PATRIOT Act. A foreign government therefore has no legal route to enforce access to the stored deposits.
Our hosting infrastructure runs solely at independent parties within the EU, not at US providers or their European subsidiaries. In combination with our zero-knowledge architecture, in which Softcrow never receives the encryption key, the contents of a deposit are in any case accessible to no one, not even to Softcrow or the hosting parties.
What does the US CLOUD Act mean for my escrow deposit?
The CLOUD Act (2018) obliges US companies to provide data to US authorities by order of a US court, even if that data is physically stored outside the US. That also applies to foreign subsidiaries of US companies. A contract under Dutch law offers no protection against this: the CLOUD Act works through the shareholder structure, not through the choice of law in an agreement.
For escrow this is relevant. An escrow deposit often contains the most valuable intellectual property of a software company: source code, architecture descriptions, configurations. If the escrow agent falls within the scope of the CLOUD Act, that deposit is in principle reachable via a US court order.
When choosing an escrow agent it is therefore worth checking whether that agent has a US parent company, is incorporated in the US, or is otherwise subject to the CLOUD Act.
Zero-knowledge architecture adds an extra layer to this. If Softcrow has no access to the contents of the deposit (which is the case, because Softcrow never receives the encryption key), then there is nothing meaningful to provide, not even under compulsion. What can be enforced is the encrypted deposit without the key. That is technically unusable.
Softcrow is an independent Dutch company. But the strongest guarantee is not legal in nature: it is the architecture. Because Softcrow never receives the encryption key, there is nothing meaningful to provide, regardless of which legal system would apply.
Does my data fall under the US CLOUD Act?
No. Softcrow’s storage infrastructure, SecureStorage, is hosted entirely within the EU, under EU law and the GDPR, and falls outside US jurisdiction. The US CLOUD Act and the USA PATRIOT Act do not apply to it: Softcrow is an independent Dutch company, without a US parent company or incorporation through which a US order could be passed.
On top of that comes the zero-knowledge architecture. Softcrow holds no keys, so the data is mathematically unreadable for Softcrow and for the hosting parties. Sovereign, CLOUD- and USA PATRIOT Act-free storage and zero-knowledge reinforce each other: your deposit is not reachable via a foreign legal system, and were the encrypted deposit nevertheless requested under compulsion, then it is unusable without the key.
Why don’t you synchronise with our Git system?
Automatic Git synchronisation is sometimes promoted as a clever, modern way of delivering. That is an understandable marketing message, but for escrow it is the wrong choice, for three reasons.
The first is zero-knowledge. With direct Git synchronisation the escrow agent receives the source code in unencrypted form. The agent thereby has access to the intellectual property of the supplier. That is exactly what you do not want. In Softcrow’s escrow process the supplier encrypts the deposit itself, client-side, before delivery. Softcrow receives only encrypted files and never holds the encryption key.
The second reason is infrastructure independence. Escrow exists precisely for situations in which the supplier’s normal business operations are no longer possible: bankruptcy, ceasing the service. A direct link with the supplier’s Git system means that the deposit depends on the same infrastructure that may no longer be available in an emergency. That undermines the purpose of escrow. Such synchronisation moreover assumes a pull by the escrow agent. We do not believe in that. At Softcrow it is the reverse: a push by the supplier itself, to our append-only storage environment. After receipt nothing can be changed anymore and we periodically validate the integrity of what is stored.
The third reason is the definition of a deposit. A Git synchronisation deposits with every commit, not with every release. A deposit in the escrow sense is an identifiable, release-ready version that a beneficiary can actually use in an emergency. Intermediate commits are development snapshots, not a deposit. When every commit is automatically deposited, it is moreover unclear which version is the official one the beneficiary can lay claim to.
Automation is no objection: the Softcrow CLI supports automated delivery via pipelines, at the moment of a release. What Softcrow rules out is that automation comes at the expense of confidentiality, independence or the integrity of the deposit.
Why no proprietary encryption or cloud integrations?
Some providers position direct cloud integrations and proprietary encryption as the modern approach. Some dismiss the use of ZIP as old-school. Softcrow deliberately takes a different route. That is not a lack of ambition but a matter of principle.
Escrow agreements run for decades. Proprietary formats and platform dependencies that are modern today may form an obstacle in ten or twenty years’ time, precisely at the moment the deposit matters most. AES256-ZIP is an open standard supported by every common archiving program, independent of whichever supplier or whichever platform.
The strength of AES256-ZIP is largely determined by the strength of the chosen encryption key. That is why Softcrow generates a quantum-safe key by default: 43 characters, Base64 URL-safe without padding, generated with crypto/rand (Go).
Quantum safety, no vendor lock-in and future-proofing are not side issues. They are the core of what good escrow should be.
How do I ensure that the right information reaches the right beneficiary on release?
That starts with the structure of the deposit and the deposit specification. If your agreement covers several beneficiaries, or if you supply software that differs per customer, it is wise to build this into the deposit structure. Make clear per beneficiary or per product which files, modules or components are relevant for them, and describe this explicitly in the deposit specification. The deposit specification is the only readable information available on release; a clear structure prevents ambiguity at the moment it matters.
What does release mean for me as a supplier?
On release the deposit is released to the beneficiary. The supplier is aware of this, but cannot block release if the laid-down conditions have been met: that is the essence of a neutral custodian. Softcrow checks the conditions and coordinates the process. A well-delivered and verified deposit makes the process smooth. For the supplier, release is no surprise but the logical end point of the arrangements made when the agreement was concluded.
Is your question not listed?