In the normal course of business, especially within the project business (e.g. construction) an applicant will need to arrange for a guarantee to be issued in favor of a beneficiary (normally its customer or buyer). The applicant will do this through a Guarantor (financial institution) that will issue the guarantee contract and be obligated by its terms. Today's challenge is that the storage of guarantees is decentralized while the guarantee related process is manual and paper based. The Guarantee Vault Platform seeks to create a centralized digital register that replaces the issued paper guarantee with its digital version. The digital guarantee would be issued by the guarantor on the GVP register and would retain the same legal authority as that held by the paper guarantee today.

GVP API looks to improve efficiency and increase transparency by replacing the decentralized paper process today with a centralized digital one that puts all market participants on the same digital page.

System Overview

At heart, in its simplest form, the system allows:

• Applicants to request the issuance of digital guarantees
• Guarantors to accept and issue digital guarantees to beneficiaries
• Post issuance, the system allows applicants and beneficiaries to make certain requests (changes) to the issued guarantee has highlighted below.
  • Issuance – Applicant only
  • Amendment – Applicant only
  • Release – Both Applicant & Beneficiary
  • Claim – Beneficiary only

With all participants using the same platform and rules, GVP will allow for a more streamlined end to end process. Once the guarantor validates, approves and issues the guarantee, the applicant will have the possibility to make it immediately available to the beneficiary via GVP. The beneficiary at that point (whether registered with GVP or not) will then have access to the guarantee in GVP with the possibility to view details or even print the guarantee if required.

Although GVP will be available through a user interface, the majority of participants will interact with GVP using APIs to their proprietary in-house systems. This document will detail the API specifications for Applicants.

Scopes

Authentication process

Relying Party will authenticate using its client_id (created during registration) and the private_key_jwt (according to OpenID Connect Core 1.0 chapter 9).

During the authentication process the Relying Party should generate a JWT token as described in RFC7523 section 2.2 and sign it using their private key and the RS256 algorithm (RFC7518 section 3.1).

If the Relying Party has been registered with "JWKS URL" option, the client developers should implement the corresponding endpoint on the guarantors side that returns public key(s) used for the verification. Then implementation should be done according to RFC7517 (page 10).

API Service account registration

Company admin users can create service accounts for a Relying Party. GVP system will generate a client_id for the new service account and then, the company admin will choose an application name (an informative label) and select the method to transmit the client's public key or certificate. This could be done via:

1. JWKS URL endpoint (preferred)
2. Manual file import
3. Generating a keypair on the authorization server

The keypair will be required for the verification process. The preferred option for key handling is using the JWKS URL.

Using JWKS URL, the new keypairs will be downloaded from the client's JWKS endpoint. The other methods of communicating key-pairs will involve a manual step where company admin user re-imports the new key or certificate.

Access token expiration

• Access token - expires in 1 hour
• Refresh token - expires in 2 hours

When the access token expires, the Relying Party shall use the refresh token in order to get a new access token or repeat the authentication process from the beginning.

Participants should implement this functionality or use any libraries that already provide a refresh token functionality “out of the box”.

Error object specification based on RFC7807

Errors that return an error object will always return a JSON object with attributes as specified below.

• type - string

  • A URI reference [RFC3986] that identifies the problem type. This specification encourages that, when dereferenced, it provide human-readable documentation for the problem type (e.g., using HTML [W3C.REC-html5-20141028]). When this member is not present, its value is assumed to be about:blank.

• title - string

  • A short, human-readable summary of the problem type. It SHOULD NOT change from occurrence to occurrence of the problem, except for purposes of localization (e.g., using) proactive content negotiation; see [RFC7231], Section 3.4).

• status - number

  • The HTTP status code ([RFC7231], Section 6) generated by the origin server for this occurrence of the problem.

• detail - string

  • A human-readable explanation specific to this occurrence of the problem.

• instance - string

  • A URI reference that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced.

This API will cover the following workflow actions / scenarios

• The API is intended for usage with a system that usually receives incoming data either in a queue or batch-based manner.
• The API assumes that the consumer of the API has a good understanding of the various steps in handling guarantees.
• The interaction of the API is based around an end-point that presents notifications.
• Notifications are references to new or changed business objects (e.g. guarantee request / issuance and post-issuance events such as amendments, releases, and claims),
• These business objects may include links related to file resources.
• The referenced business objects are expected to be downloaded and persisted in the client’s system, after which the notifications are “acknowledged”.
• The objects are available even after being acknowledged, but will never change without a notification.
• In the Guarantors system, decisions affecting the various business entities are made, and these are posted back into the GVP system as POST- or PUT-requests.
• Error/successes are being transmitted back to the client via the HTTP response.
• Successful transactions shall also appear listed in the notifications.
• PUT update requests currently need to supply a complete copy the initial POST, including attached files.
• Use ISO-8601 date format for all business-related dates in requests/responses.
  Business-related dates examples: Issuance Date, Expiry Date, Reference Date, Reference Expiry Date, Release Date etc.
• Use ISO-8601 datetime format for all system-generated dates in requests/responses.
  System-generated dates examples: Decline date, Request Date, File Uploaded Date, Notification Creation Date etc.
• All system-generated dates will be returned as datetimes in UTC
• The maximum size permitted for uploaded files is 10MB
• The maximum size allowed for requests(multipart/form-data or application/json) is 21MB
• All the date fields are allowed between years '0001' and '9999'

Unregistered Beneficiary

When submitting a guarantee request through the POST: /applicant/v0/guarantee-requests endpoint, the beneficiary can be submitted using the uuid of an already registered beneficiary. If the beneficiary is not yet registered in the GVP or the uuid is not known, the details can be provided in the guarantee request instead. The beneficairy is now known as an Unregistered Beneficiary and the GVP response includes the uuid for this beneficiary. The GVP system will create a new entry in the Local Address Book of the consumer for any new Unregistered Beneficiary. For any subsequent request, GVP will try to identify the beneficiary now based on the beneficiary.name and beneficiary.email. If there is a matching entry already in the Local Address Book of the consumer, this beneficiary (e.g. the same uuid, address, details) will be used as a beneficiary.

Identification of incoming applications

• Prior to receiving any guarantee requests from a specific applicant, the applicant admin user must submit a “connection request” to the guarantor admin via the GVP web UI.
• On accepting the “connection request” on the GVP web UI the guarantor admin will be prompted to provide their Unique Customer Id for the applicant in question
• When receiving guarantee requests from applicants via the API, GVP shall dynamically add this unique Customer Id to the incoming request allowing the guarantor to immediately identify the applicant in their proprietary system.

1. The applicant sends guarantee request to GVP
2. GVP dynamically adds guarantor’s unique Customer Id to the request
3. As the guarantor’s system polls the notification endpoint, the guarantee request shall be listed in the notifications.
4. The guarantor shall then download the guarantee request and referred attachments.
5. It is expected that the data shall then be persisted in the guarantors proprietary system for financial guarantees.
6. The guarantor shall then process the request at which time it shall have the following options:
   1. Return the request to the applicant
      • In this case the guarantor shall provide a reason for the return
      • The applicant shall have the possibility to edit and resubmit the request to the guarantor
      • In these cases where the request has been subsequentially re-sent to the guarantor the status shall be display as RESUBMITTED
   2. Issue the guarantee as requested by the applicant
      • On issuance the guarantor shall provide:
        1. The guarantor unique reference for the guarantee
        2. The issuance date
        3. The guarantee contract
      • The guarantor shall have the possibility to submit the guarantee contract as:
        1. Attached file (file types allowed to be confirmed)
        2. HTML text with format and images (to be confirmed)
   3. If the guarantor issues the guarantee, the records on the GVP central register are adjusted to reflect the issuance
   4. The applicant and beneficiary are notified and shall have access to the digital guarantee on the GVP register. The newly issued guarantee shall also appear listed in the notifications of the guarantor.

As well as manually polling the notification API, any API Client can subscribe to notification events in the GVP system through Webhooks.

Configuration

Company admin user will have an option to configure the following webhook parameters for the API client:

• Payload URL - endpoint URL that will receive the webhook POST requests (will be exposed from the client side)
• Content Type - application/json or application/x-www-form-urlencoded
• Secret - the secret that will be used for HMAC signature generation(see details below)
• Activate flag - for enabling/disabling webhook
• Notification types - the notification types that the client is interested in (GUARANTEE_REQUEST, GUARANTEE, AMENDMENT, RELEASE, CLAIM, CLOSE, REOPEN)
• Version - GVP API version that API client uses (V0).

Usage

The HMAC signature will allow the API client to ensure that POST requests sent to the Payload URL are from GVP.

GVP will calculate a signature (based on a secret, the notification payload and the `HMAC SHA256` algorithm) and include it into X-Vault-Signature header in the webhook POST request as Base64-encoded hex value. The Client should implement the signature verification for these requests.

There are no retries of failed webhook deliveries and no API for listing or retrieving failed webhook events.

Therefore, the client service that exposes an endpoint for webhooks (see Payload URL) must be highly available. In case of any issues/maintenance on client service, API client should itself request/poll /v0/notifications/new endpoint (provided by GVP) in order to get missed notifications.

The notifications received through the webhook mechanism should still be acknowledged through the Acknowledge endpoint after being persisted by the Client API.

When processing the requests to the API, different errors and exceptions can occur. The error states are listed in each request.

Most of GVP errors can be found on https://api-docs.guarantee-vault.com/errors/ErrorResponses.html

title field in response body displays exception type

type field in response body points to specific error description. For example, https://api-docs.guarantee-vault.com/errors/ErrorResponses.html#InvalidGuaranteeParticipantException

What is the purpose of the explicit Acknowledge function?

The explicit “Acknowledge” is required as the GVP system needs confirmation that each system has received the expected data.

When an Acknowledge is made by the client to GVP, GVP assumes that client received the data correctly and that it has been securely persisted into its proprietary system.

Without this explicit acknowledge, it is impossible for GVP to be certain that there were no technical difficulties and that the data was correctly received by the client’s system.

Will reporting of the items be provided via API?

Currently this is not within the scope of the API however this will be made available via the GVP web UI.

If there are any questions regarding the API of the GVP system please contact us at [email protected].

This changelog lists all additions and updates to the Guarantee Vault API, in chronological order. Changes can be in the following categories:

• [added]: Added fields, endpoints or functionality
• [changed]: Changes to existing data models
• [removed]: Removed fields or functionality

14. January 2025

• [added] Endpoint 'Guarantee Reopen'
• [added] Endpoints 'Corporate Guarantee Reopen'

06. June 2024

• [added] New attachment section guaranteeFilesLibrary added for guarantee-request and guarantee response models - this will be filled, if wordings from the wording library feature were supplied. Supplying library wordings is currently only availiable in the GVP UI.
• [changed] If guaranteeWording OTHER was selected, it is now also possible to provide guaranteeFiles attachments or guaranteeText.

20. November 2023

• [added] Field governingLawSubdivision for specifying the Subdivision of a Governing Law Country in a Guarantee.
• [changed] Field placeOfJurisdiction in a Guarantee can only be filled if governingLaw is filled.
• [changed] Field deliveryAddress in a Guarantee can also be filled optionally if APPLICANT, BENEFICIARY or OBLIGOR was selected to capture delivery details.
• [changed] Field deliveryAddress in a Guarantee increased to 780 characters.
• [changed] Field reason in an ask-release request increased to 1000 characters.

09. October 2023

• [changed] Limit all issuance reference fields (issuance.ref) to 140 characters (guarantee, amendment, claim, release).

24. July 2023

• [changed] Amendment Issuance files: minItems: 0 and maxItems: 10, not mandatory.

The notifications gives the system a list of data of various types. The client should GET the document and referenced file resources. When the client is certain that the data is persisted to its system, a call to the Acknowledgement should be made.

The various resources will be available until they are explicitly acknowledged.

The guarantee request enables the applicant to submit a guarantee request, retrieve an overview of guarantee requests, retrieve the details of an individual guarantee request, and update a guarantee request in case it has been returned by the guarantor.

The guarantee enables the applicant to retrieve the list of issued guarantees and retrieve the details of individual guarantees after issuance.