Heralded as a “first” for the industry, the International Chamber of Commerce (ICC) and Swift have thrown their weight behind producing application programming interface (API) standards for guarantees and standby letters of credit.

In recent years, trade finance banks have increasingly rolled out their own API guarantee standards or connected their systems to corporate customers through fintech platforms, resulting in faster turnaround times for financing applications.

But there has been mounting concern in the industry over the proliferation of such standards and the wider threat posed by so-called “digital islands”, which some fear could derail broader trade finance innovation.

The Swift-ICC standards have been written to align with older Swift message types and are also compliant with the ISO 20022 standard, which creates a single format for transactions across different systems, platforms and geographies.

The announcement comes on the back of a months-long consultation involving ICC and Swift members, including financial institutions, companies, fintech platforms and service providers – and a pilot is now being lined up.

GTR speaks to Shirish Wadivkar, Swift’s global head of wholesale payments and trade strategy, about why there is a need for the API standards, the benefits they could bring and the potential challenges facing their rollout and adoption in the trade sector.


GTR: What is driving the need to introduce API standards for bank guarantees?

Wadivkar: In the past, the MT798 format has been used by corporates to apply for, amend or cancel bank guarantees via the Swift messaging service, or companies have relied on paper-based processes and emails.

There has been a growing interest in APIs, with banks developing their own APIs to link clients to their platforms, or trade finance fintechs are providing software that connects a corporate’s enterprise resource planning (ERP) system to multiple banks.

There is a clear need to create some uniformity in the industry, as there hasn’t been a uniform standard for APIs to accompany their growing usage and adoption across corporate-to-banks channels. A proliferation of standards slows down widespread adoption and growth. Imagine a corporate which has relationships with multiple banks: currently, they must interact with various standards when applying for a guarantee issuance. If we continue down the same path, we’ll end up in a situation with a highly fragmented landscape.

What we have is an interoperable and open industry API standard, not just for the Swift network, but in collaboration with the ICC, which is widely and publicly available, and is aimed at the design of corporate to bank interfaces. This will benefit the community as a whole, as there will be reduced friction, richer data and standardised processes.


GTR: How have the ICC and Swift standards been designed and what benefits will they bring to the trade finance industry? 

Wadivkar: The Swift and ICC standards are open and have been devised to be compatible with both the old MT798 and brings in a few elements from ISO 20022 standards approach too. Whether you are a Swift corporate customer applying for a guarantee over the Swift network, or you are a non-Swift corporate using a set of APIs provided by a bank, or you are using a third-party integration layer for trade transaction processing, the idea is everyone can use the same API standards for the bank guarantees.

The new bank guarantee API is essential in instances where there are high levels of process automation, a process redesign is being considered, or a B2B marketplace between the buyers and suppliers. Quick and integrated issuance of guarantees are at times critical. By creating unified trade guarantee standards, Swift and the ICC are hoping to make multi-bank interactions more efficient and less costly for all participants. The cost of “data translation” and associated risks will be decreased with such standardisation.

The new API also enables trade finance platforms, as well as corporates and banks, to align all their trade data. If we want to ensure total trade digitisation can happen – and that is our long-term goal – it is crucial that data is standardised. In general, the handling of bank guarantees is still very manual and inefficient. APIs would aim to increase process automation and digitisation of trade, with corporates able to automate the information gathering process from their ERP systems as an example.

By cleaning up the corporate-to-bank segment and standardising this information currently, this should speed up other stages of a corporate-to-bank guarantee transaction.


GTR: What are the challenges facing the widespread adoption and implementation of these standards?

Wadivkar: There are a couple of aspects here. If a bank has already a single API running for its corporates, it may have less of a need to modify its API for this proposed standard. The second aspect revolves around the fact that the new guarantee standard may not really generate new revenue on its own. But a guarantee standard used by the entire industry will reduce the total cost of processing.

Thankfully, through the ICC and Swift consultation, banks and corporates understand the potential benefit of standardisation. The easier it is for their corporates, no matter their sizes, to apply for guarantees, the more likely lenders are to retain that business and hence their participation with the ICC and Swift in the design of a common standard.


GTR: What is the future road map of the Swift/ICC API standards? Will they be replicated for other use cases beyond guarantees?

Wadivkar: Swift is set to run a pilot involving banks, corporates and third-party vendors for these new API standards. The pilot will cover the lifecycle of the guarantee and will look at the issuance, amendment, cancellation or release stages of the transaction. The new standards are focusing on the corporate-to-bank portions of a deal, so this is the area Swift and the ICC will be assessing as part of the trial process. This could include the applicant and beneficiary companies, banks, and could also include their interface providers. Initially, we are starting with guarantees and then we will look to standardise documentary letters of credit in the future.