Banking the Underbanked: Blockchain-Powered Digital Trade Platform for SME Banking in ASEAN

Synopsis: This article proposes a digital trade platform targeting SMEs as a top strategic initiative for wholesale banks in ASEAN, exploring the business opportunity, challenges to be addressed, platform design principles and key technology enablers:

• The ASEAN SME segment has been identified as a key growth opportunity by many banks, but achieving sustainable profitable growth in this segment has proven to be an up-hill challenge.
• Banks must focus on capturing trade flows to establish primary banking relationships in order to maximize value to the bank while minimizing risk within this segment.
• Achieving this requires a customer-centric approach, understanding and addressing SME pain points around trade not limited to banking services and solutions.
• An electronic trade platform that supports SMEs in digitizing trade documentation and workflows, and seamlessly availing of transaction banking services is the killer app to address trade-related pain points for ASEAN SMEs.
• Emerging technologies like cloud, permissioned blockchains, AI-enabled robotic process automation and API-based open banking architectures have the potential to enable a digital platform that raises the bar in customer experience to a new level.
• This platform can also be a stepping stone for further expansion into new business models and sectors, such as a combining logistics management and trade finance platform leveraging Internet of Things (IoT).
• Innovative banks able to drive digital transformation beyond traditional banking services to offer customer-centric technology solutions are at a time ripe with opportunities for growth. It is also a time of grave threat for those banks that aren't.

The SME segment is a key strategic growth opportunity for most ASEAN banks, but establishing primary banking relationships to achieve sustainable, profitable growth in this segment can be a tough challenge

According to a study by Deloitte, SMEs in ASEAN contribute between 30-60% of each market’s GDP and account for 60-90% of employment. Yet, approximately 50% are underserved, making it a sizeable opportunity pool for wholesale banks to expand into.

However, achieving sustainable profitable growth in the SME segment presents significant challenges for most banks. As a whole, the segment is higher risk and in many cases suffers from poor cash flow visibility. Digging deeper, the more ‘bankable’ portion of SMEs is not underserved – in fact, it is arguably saturated. The leading banks in each market hold the primary banking relationships, covering transactional accounts, credit and trade finance needs, while other banks will provide additional secondary credit lines that are underutilized and, if used, it is under strained cash flows and often paid off last. For ‘best of the rest’ banks, this means little value and high risk.

To achieve a worthy risk-return in the SME segment, winning over the primary banking relationship becomes critical. It provides greater visibility over the company’s overall financial health for risk assessment, a diversified product mix and greater customer loyalty. “Tick the box’ customer acquisition is the easy part –the real challenge for ‘best of the rest’ banks in competing with banking leaders is converting these from underutilized credit-only customers to long-lasting primary banking relationships spanning multiple products. And the key to achieving that is capturing the client’s trade flows.

“Capturing trade is the foundation of a primary wholesale banking relationship. Facilitate trade flows and your bank will become the obvious choice to deposit and transact from, paving the way for deeper customer relationships.”

Transaction banking typically accounts for approximately 15-20% of wholesale banking revenues. This includes cash management and payments, as well as trade finance (e.g. letters of credit, bank guarantees, receivable financing, etc). Trade finance accounts for approximately 35-40% of this. It may seem relatively small, but the “size of the prize” in capturing this portion of clients’ business is by no means limited to the trade revenue pool – it serves as a gateway to significantly deeper relationships with wholesale banking customers.

Banks that excel at trade-related services have enjoyed significantly higher returns on capital. These services support the core daily operating activities of the client and have a natural adjacency to other banking products such as deposits and non-interest products like FX. Hence, strong coverage of trade activities typically result in greater customer loyalty, less volatile revenues, higher product penetration and lower loan-to-deposit ratios that help reduce cost of funds and widen net interest margins.

But just throwing away prices on trade products as a hook to lure customers into a wider product bundle isn’t going to cut it. And competing on having a wider regional or international footprint to better serve cross-border trade is simply not an option for most banks. Regional and international banks may have a head-start, but they are rarely top tier across multiple markets (not unlike the regional companies they serve) and if you are not one of those banks, you’ll have to play with the cards you have.

To win, banks need to take a customer-centric approach focusing on solving needs and pains around trade, often going over and above offering traditional banking products and services. So what exactly are we solving for?

“For most SME customers, it is not the inability to access trade facilities or pricing that they suffer from the most – the true pain point is transactional friction. Mountains of paperwork, inconsistent forms, manual processes, burdensome documentary requirements, long turnaround times… those are the real headaches.”

Many SMEs and even some lower tier commercial segment businesses in ASEAN still handle invoices and purchase orders in the form of physical paperwork. The forms are far from standardized and often have important information missing about the trade. This has a grave impact on efficiency and cost.

For the customer internally, extensive manual processes are required, increasing error rates and imposing a big burden on resources. The information in these trade documents needs to be manually recorded into digital systems of record, which can often be as rudimentary as Excel or a basic accounting application. Payment instructions then need to be manually generated and conformed to bank standards to then be sent (sometimes even physically brought to) a designated branch for manual execution, while incoming payment reconciliation against invoices is done manually and requires a team of multiple FTEs.

When it comes to availing of trade finance services, since banks will typically require to inspect the trade documents, sub-par heterogeneous documentation results in limited eligibility for financing and extensive back-and-forth between trade partners and the bank. Moreover, SMEs will likely need to make several trips to the branch to manually exchange physical documentation. This means longer turnaround times, lower operational efficiency, higher costs and a poor customer experience.

In contrast to larger wholesale clients and even smaller businesses in more developed markets, SMEs in ASEAN lack the more sophisticated ERP software integrated with host-to-host cash management systems or even access to enterprise-grade online banking services, making both internal operations and interactions with the bank less integrated, automated and efficient.

“While not all of these pains are caused by the bank itself, they are arguably still the bank’s problem to deal with. The client has a pain point and, bank-related or not, solving it is the key to winning over the relationship.”

So what would the ideal solution look like? At a high level, it would have four main pillars:

Pillar I: Facilitate Customer Digitization: SME customers need a solution to help digitize all trade documentation (i.e. trade agreements, purchase orders, invoices…) and modernize their accounting and resource management. Customers should able to:

• Scan trade documents using optical character recognition (OCR) and AI to process data into structured digital records (e.g. identify terms such as price, quantities, entities, dates, etc.);
• Create new trade documents (e.g. invoices, purchase orders) using given best-practice templates;
• Auto-generate and export payment instructions, as well as import account statements to reconcile payments with invoices;
• Track working capital health and payments due, providing alerts and recommendations.

Pillar II: Electronic Documentation Exchange: Once documentation is digitized, the solution should include a platform to facilitate the secure exchange of trade and financing documentation between trading partners, as well as with banks providing trade services. Every trade would be executed via electronic document exchange on such a platform in the ordinary course of business (i.e. not limited to trades being financed). Requests for trade finance can also be submitted to the bank via the platform, which would already hold the relevant trade documentation (and provide the bank with greater cash flow visibility for risk assessment).

Pillar III: Automated Workflows: Customers should be able to avail of trade financing and services and trigger payments on the platform at the click of a button, or automatically upon the occurrence of a pre-determined event, with minimal manual intervention. This includes, for example, back-office verification by the bank that a request for receivables financing complies with the terms of the trade facility contract and does not exceed credit limits (implying advanced digitization and automation of the bank’s middle office).

Pillar IV: Integrated systems: The platform should provide simple and secure integration with (i) the bank’s core banking systems, to enable trade services such as payments and trade facility drawdowns to be executed; and (ii) the participating client’s systems of record – whether it is the above digitization tool adopted by the customer, and/or its existing accounting software - to ensure these are updated as transactions take place on the platform. Note that the solution described in Pillar I need not become the company’s core system of record, but if it has to co-exist with an overlapping application, these must be kept synchronized real time.

Such a solution would provide immediate value added to the SME customer helping them digitize and improve financial management, creating a clear incentive for adoption. Once adopted, the client gains access to a best-in-class experience in transaction banking provided by the electronic exchange of trade documentation, automated workflows and integrated systems.

It is clear that the bank itself must go through a degree of internal digital transformation to make at least one side of this model possible. For many banks, this will likely already be part of a wider digital transformation agenda, as most banks have embraced the need to digitize to remain relevant and competitive.

But what about the transformation required of the customer? What role should the bank play in that?

For most banks, digital transformation is still about using technology to improve the performance of its core business. However, the imperative for digital transformation today goes much deeper. In many cases, it requires banks to go beyond their core business, adopting new business models to effectively become a technology company - that is, to offer technology products and services. This is one of such cases.

“Banks are uniquely placed to develop and monetize a digital trade platform to address these pains and needs, enabling customers to seamlessly (i) upload, create, manage and exchange digital trade documentation; and (ii) seamlessly avail of transaction banking services from their bank, including drawing down on trade finance facilities based on the digitized documentation held on the platform.”

This platform may be exclusive, with the providing bank as the only trade financier on the platform, or open to other financial institutions to offer trade services on the platform (developing an ecosystem play). Monetization may be based solely on the expectation of increased business volume resulting from the improved customer experience, or may also include subscription/transaction fees charged to customers and/or other bank members. In each case, selecting the optimal business model and approach to monetization will require diligent financial projections across multiple scenarios.

In developing a digital trade platform, banks should adopt several key technology enablers and design principles:

Pillar I: Partner with a Cloud service provider to leverage an existing SaaS solution for digitization and ERP capabilities

To help SME customers digitize and optimize their resource management, the proposed digital platform will need to provide a light ERP-like tool module. To do so, banks are best advised to partner with an established third party vendor.

While this is a critical value-added designed to induce adoption of the overall digital trade platform, it is not the key point of the differentiation. It is a gateway to the truly innovative customer experience provided by the trade banking functionalities of the platform that are the core of the platform proposition.

Partnering with an established technology provider will likely be more efficient and effective than developing this pillar of the solution in-house.

There are multiple providers of these types of solutions, many of which have shown their willingness to partner with banks based on licensing and revenue sharing-schemes. Examples of these applications are Xero and SAP One, are already engaged in non-exclusive partnerships with multiple banks in ASEAN. Oracle ERP Cloud also offers a strong and highly scalable SaaS solution for SMEs.

A software-as-a-service cloud delivery model would likely be the simplest and most effective. For the customer, it reduces IT operations complexity as provisioning, upgrading and patching are managed by the vendor. It is also easier to scale as the company grows. For the bank and vendor partnership, it will also make it easier to monitor usage and operationalize a revenue-sharing mechanism.

Pillar II: Leverage permissioned blockchain technology to enhance security and trust within the platform

Banks rely on trade documentation to provide customers with trade credit facilities and services. These documents - and the underlying transactions and assets they reference - shape the pricing and risk profile of the trade services offered by the bank.

Trade documentation is subject to a heightened risk of fraud, including forged invoices, fake letters of credit, duplicated collateral warrants, etc. Bank fraud is not an unusual occurrence in trade finance and can cause significant losses. Earlier this year, Punjab National Bank in India disclosed a $2 billion fraud involving fake letters of credit. International bulge bracket banks have also been affected. Standard Chartered lost almost $200 million from a fraud at China’s Qingdao port two years ago, while JP Morgan was caught out in a transatlantic conspiracy using fictitious purchase orders and invoices defrauding several banks of close to US$700 million.

The use of blockchain technology could help minimize the risk of fraud in trade finance. Many banks have already started exploring this use case. Standard Chartered and DBS teamed up to develop a blockchain-based electronic ledger of invoices. Bank of America and HSBC have also announced they are exploring blockchain for trade finance. J.P. Morgan has even developed its own blockchain framework – Quorum – a permissioned version on Ethereum for enterprises in various use cases.

Blockchains are distributed, de-centralized database management systems where data entries are validated by multiple independent nodes and committed following a pre-determined consensus protocol (e.g. proof-of-work, proof-of-stake, proof-of-authority, etc). Once a data entry is committed, it creates a reliable, auditable trail of transactions, making the ledger immutable.

Hence, two parties reflecting a trade on a blockchain-based trade platform would independently validate (via cryptographic signature) the documentation submitted, preventing one of the parties from forging an invoice or purchase order to fraudulently draw trade credit from the bank. In a letter of credit scenario, the issuing bank would register the letter on the blockchain, making its authenticity verifiable by the advising bank. In another example, assets to be collateralized could also be ‘tokenized’ and registered on the blockchain, allowing other lenders to audit and discover other liens.

Using blockchain effectively to achieve the intended benefits in this use case presents numerous challenges, but these can be mitigated by making optimal design choices:

1.      Select a highly interoperable blockchain framework

The aforementioned use cases for fraud prevention depend on adoption of the platform by all participants involved in each trade. For example, if the trading counterparty to a customer is not a participant on the platform, the blockchain will not prevent the customer from furnishing the bank with a fake invoice.

Banks can bolster adoption in a number of ways - being quick to market with the platform to gain early mover advantage, creating a seamless onboarding process and designing a monetization model that charges only to and when a participant is deriving a tangible benefit from the use of the platform. However, it seems somewhat farfetched that any particular bank would be able to roll-out a monopolistic platform to rule the global trade finance market.

Hence, instead of aiming for monolithic platform adoption, banks should seek to build their platform on a highly interoperable blockchain framework that will be able to interact with the widest range of other blockchain-based digital trade platforms that may become available in the future.

As of today, Linux Foundation’s Hyperledger Fabric project would arguably be the prime candidate.

2.      Configure a permissioned blockchain featuring private channels

The trade finance platform will support the exchange of highly sensitive commercial information – who is trading with whom, how much, at what price, with how much leverage, etc. It is therefore critical to ensure that this information can be exchanged confidentially and prevent it from falling into the wrong hands. Robust identity management is also critical to the success of the platform to ensure privacy and transaction authentication by authorized parties.

At a very high level, public blockchains ‘secure’ data by creating a practically untamperable, auditable record of transactions through a principle of de-centralized transparency. The fundamental premise is that every data entry is broadcast to every node in the network, which independently verifies it and follows a pre-established consensus protocol to agree on a golden record.

This approach offers several advantages over more traditional centralized means of securing data (i.e. no trusted counterparty required, no single point of failure, etc) but, since every transaction is being sent to every node and anyone can set up a node on the blockchain, privacy is not one of them.

A permissioned blockchain that features private transaction channels, like Hyperledger Fabric, can help overcome these privacy and security challenges.

Permissioned blockchains use an identity and access management layer to administer who can interact with the network and how. Unlike public blockchains, which allow anyone to participate in the blockchain with equal authorities, permissioned blockchains can limit access only to known nodes that have proven their identity, and give participants different levels of access to the ledger (e.g. read, validate, issue tokens, etc.) This type of blockchain would allow the bank to limit access to the platform to known customers and partner banks (e.g. who have fulfilled KYC requirements) keeping out unauthorized parties to improve security, and reflect differentiated roles within the platform (e.g. customers vs. banks).

A permissioned blockchain offers additional protections over public blockchains by limiting access to the platform. However, privacy concerns are still present if all transactions openly executed on a single ledger, since it would allow all users on the platform to view everyone else’s transactions, potentially exposing commercially sensitive details to competitors, suppliers and customers. To address this, Hyperledger Fabric provides for the configuration of “Channels”.

Channels are separate ledgers that allow a subset of members to the blockchain to transact privately. These channels are completely isolated from the general ledger. They may share ordering service node(s), but these are only responsible for timestamping and sequencing transactions, not transaction execution (signature authentication, validation, etc.) Thus, the transaction details need not be made “visible” to them - inputs can be excluded and outputs can be hashed/encrypted.

Note that these are fundamentally different to the “private payment channels” that are gaining traction around public blockchains, (e.g. Lightning Network) in that these do ultimately anchor back to the main blockchain ledger (e.g. Bitcoin, Ethereum) and are designed more for scalability and transaction cost reduction than privacy. These type of channels hide the frequency and quantum of individual transactions, but do reveal the address of, and eventually the net value exchanged between, the counterparties.

3.      Keep trade documentation off-chain to optimize platform scalability and throughput

A blockchain keeps an auditable historical trail of transactions and replicates them across all participating nodes. This makes blockchain a wildly inefficient storage solution by design. Over time, keeping trade records of all members (invoices, purchase orders, letters of credit, credit agreements, etc.) would impose enormous requirements on the network. According to a study by BCG, global trade finance transactions represent around 600 million documents, 4 billion pages or 20 billion data fields.

It is worth remembering that the primary purpose in using blockchain for the proposed trade finance platform is to prevent fraud by having the parties to a trade authenticate transactions. This can be done without the need to store all trade documentation on-chain by leveraging cryptographic hashing.

A hash function takes a variable length data input and converts it into a fixed length output. It is a one-way function and any small change in the input data significantly alters the output, making it impracticable to reverse engineer the input data based on the output.

Hashes of the trade documents can be committed to the blockchain in a signed transaction by the parties. This creates auditable proof that the transaction took place and, in the event of a dispute, any party can prove the true version of the trade terms by re-generating a hash that matches the one recorded in the blockchain. Meanwhile, trade documentation can be more efficiently stored off-chain in a separate traditional database.

This also provides a degree of privacy as the trade documents are hidden from other platform members, who can only view the hash. However, it is not a substitute for the privacy protection offered by Hyperledger’s channels since the identity of the parties, the timing and the historical frequency of transactions can still be seen by other members.

4.      Use a “Blockchain-as-a-service” platform to facilitate development of the network

IT providers such as Oracle, Microsoft, Amazon and IBM have released a series of ‘blockchain-builder’ platforms-as-a-service. These are effectively developer toolkits (integrated with cloud infrastructure) that make it easier and faster for organizations to configure, provision, integrate and deploy blockchains. Most of these platforms are built for the most popularized and interoperable blockchain frameworks, like Hyperledger and Ethereum, making them fit for purpose. These platforms can reduce complexity for the in-house IT teams that have to deal with intricate applications of this new technology and reduce time-to-market.

It is worth noting that combating fraud is but one of many use cases for blockchain in financial services generally, and transaction banking in particular. Perhaps the other most salient related use case is leveraging blockchain to also handle the settlement of payments. Early pilots by banks with platforms such as Ripple have shown great promise in terms of time and cost reduction, reported to range between 40-70%, (although significant throughput limitations remain). However, addressing this use case warrants a dedicated article, and has been kept outside of the scope of the present one.

Pillar III: Automate processes leveraging smart contracts and robotic process automation (RPA)

To maximize operational efficiency and minimize turnaround times for customers, back-end processes triggered on the platform (e.g. invoice payment, drawdown on trade financing, etc.) should be as automated as possible. RPA and smart contracts (or Chaincode, in Hyperledger Fabric parlance) can be used to automate business processes.

RPA platforms leverage AI-enabled software to execute repetitive, relatively low value-added processes minimizing human intervention. For example, RPA can be used to approve/reject requests for drawdowns on trade lines made by customers through the digital trade platform, streamlining the process of verifying compliance with documentary requirements and conditions precedent under the trade facility agreement, as well as credit limit availability and collateral coverage on account.

Leading banks are deploying RPA to optimize a wide range of processes with significant benefits. For example, a leading SEA bank has been able to reduce turnaround time on processing letters of credit by nearly 85%.

In turn, Chaincode can be used to automate changes to the blockchain ledger. Following our previous example, once the RPA software has successfully processed a letter of credit, a Chaincode script can be used to automatically record it on the blockchain ledger.

It is worth noting the rationale for using Chaincode to automate changes to the ledger versus the use of traditional programming languages for RPA. Chaincode is a programming language for the blockchain – it is designed for de-centralized, distributed execution, meaning the same code will be run by multiple nodes at the same time, every time. Thus, it uses more bandwidth and computational power. If there is no benefit derived from running a de-centralized computation and no transaction will be committed to the blockchain, it does not make sense to use Chaincode to program the automation.

Pillar IV: Adopt Open platform architecture capable of easy integration with a wide range of systems via APIs

The trade finance platform will need to interact with different systems of record across multiple customers (and multiple core banking systems, if other banks are allowed to participate), each of which may be using different applications and systems. Customers will expect quick and simple onboarding to the platform, and given the critical nature of the business applications involved, security is paramount. This presents significant challenges, as the trade platform will have to be able to quickly integrate with a heterogeneous set of external, business critical applications while maintaining the utmost degree of security.

Building custom integration interfaces between the back-ends of the bank and the clients’ systems would be untenable. Point-to-point integrations would result in very long onboarding times, high IT development and maintenance costs, more security vulnerabilities; and make it difficult to monitor, control and monetize usage.

The trade finance platform services are best exposed to users leveraging application programming interfaces (APIs). APIs allow software applications to communicate efficiently and securely over the internet to execute transactions. They provide a mechanism for external systems to “call” for a service over the internet using common web languages and protocols (i.e. HTTP, XML, JSON, etc.) to obtain a result without interacting with the complexities of the inner workings of the platform. At the same time, they effectively insulate the business critical systems of record of the customers and the bank’s core systems. These features result in lower integration development and maintenance costs, less downtime and increased security.

APIs also make it easier to control access, manage traffic and track usage analytics of individual services, compared to, say, exposing RESTful services using an enterprise service bus (in addition to enhanced security beyond the firewall). 

The use of APIs is well understood by most banks today but rarely implemented to their full potential, particularly in emerging markets in ASEAN. Using an enterprise-grade API cloud management platform can significantly facilitate the end-to-end API lifecycle management, including design, development, discovery, usage analytics and security. API cloud management platforms can be acquired from a range of reputable vendors, such as Oracle’s API Platform Cloud Service and Mulesoft’s Anypoint Platform.

In future, use IoT to extend the scope of the trade platform to facilitate logistics as a new business model

Let’s take the scenario of an international shipment of perishable goods (e.g. fruits) between a buyer and a seller covered under a letter of credit. Under the terms of this letter of credit, payment for the shipment will be released upon arrival of the goods at the specified port on time and in satisfactory condition (together with documentary requirements, which can be fulfilled electronically).

Connected IoT sensors can be placed on the shipment containers, measuring GPS location, temperature and acceleration throughout the journey. Upon arrival, the IoT sensors would detect that the shipment has reached the port, relay data to show that the goods have been kept within optimal temperature range at all times, and that there has been no major shock that could have ruined the merchandise. This information would be automatically submitted to the platform, where a Chaincode application would in turn execute a change in status of the trade on the ledger, prompting the RPA software to verify the inputs and trigger payment to the seller by the issuing bank pursuant to the terms of the letter of credit.

Various Cloud technology providers offer applications and middleware platform solutions to support a range of IoT use cases. Notably, Oracle offers IoT SaaS applications including asset and fleet monitoring, as well as IoT integration platforms on its enterprise-grade cloud.

This automation has a powerful impact on efficiency, turnaround times and customer experience from a trade finance angle, but it also uncovers a new business opportunity for banks – supplying a blockchain-enabled platform for the logistics service providers.

According to the World Trade Organization, 80-90% of world trade relies on trade finance. While logistics companies such as Maersk and CargoSmart are already working to develop blockchain and IoT-enabled digital logistics platforms partnering with technology companies (IBM and Oracle, respectively), a platform that combines logistics management and trade finance is yet to be launched into production. Arguably, banks would be in a privileged position to lead such an initiative.

This is but one example of an opportunity for banks to take digital transformation beyond the boundaries of its core business, developing and offering technology solutions, adopting new business models and entering new sectors.

“The industry is in a time ripe with tremendous new opportunities for agile, innovative, technologically-savvy banks. It is also a time of grave threat for those that aren’t.”