Keywords

1 Introduction

An embargo consists of the retention, by judicial order, of a good belonging to a person to assure payment of a debt, payment of judicial expenses, or of fees due to criminal acts. In Colombia, Government notification of embargoes to financial entities is currently an extensive and complex process, involving a great many public, private, or mixed economy organizations. Many state entities such as governorships (28), mayorships (1122) and hospitals (45) have the power to impose embargoes in different localities throughout the country. However, the judges who formalize the initiation of the embargo process are distributed in 3,256 courts within all jurisdictions, levels, and specialties. Recipient entities, meanwhile, comprise a large, financial group that currently consists of 23 banks, 187 cooperatives, and 27 fiduciaries located throughout Colombia with the capacity to carry out embargoes against citizens or legal residents.

In the first stage of the process, through the courts, the governmental entities issue an embargo notice. The notice is distributed to all receiving entities, without exception. Once the notice arrives at a particular recipient entity, each must execute the garnishment order for all the persons indicated and prepare a response letter indicating the details of the garnishment action performed.

During the process, a number of problems highlight the inefficiency in its execution and generate a series of cost overruns. First, there is not a complete systematization of the process. Each entity involved carries out its tasks in an isolated, different way. Although existing information systems aim to support the process, these are specific to each entity and do not interoperate one with another. Secondly, since these documents are not converted into a digital format, the embargo and response notices have to be delivered physically between the different headquarters of each entity, sent by postal mail, resulting in the additional cost of shipping to each entity. These costs affect the receiving entities to an even greater extent, since they must pay to send garnishment notices to each ID or NIT (Tax ID of a company) listed in the embargo. A third major drawback is that although most financial institutions have as clients only 2% of the people who are being embargoed, they nevertheless need to verify and provide information on the remaining 98% of the people listed in the embargo.

The receiving entities (287 in total that includes banks, cooperatives, and fiduciaries) currently receive an average of 5,000 embargo notices per month, each with a shipping cost close to USD $0.7. This generates an approximate total cost of USD $3,500 per entity per month. The process implies an average monthly cost for the receiving entities of USD $1,004,500, plus the cost of shipment from the courts that corresponds to the same value, leading to an approximate global value of US $2,009,000 per month.

The communication mechanism between the different affected entities is far from optimal. In the first place, sending notices in physical form by postal mail does not guarantee that these will always arrive on time. The situation is aggravated for the issuing entities since the people embargoed can withdraw the money just before the bank receives the notice. Another major problem is evidenced by the fact that there is no mechanism to verify if an embargo action was already executed in another entity at some point, thus all entities are obliged to execute the embargo independently of it already having been executed in another entity. This affects all the clients in these entities since once the terms of the lien are clarified they must go to each of the different financial entities remaining to request the refund of their money. Therefore, if a person has three bank accounts in different entities with balances greater than $1,000 USD and receives an embargo of $500 USD, all three banks will be forced to garnish $500 regardless of whether another entity has already executed the embargo.

The state and its entities have not implemented a technological mechanism to reduce costs in this process because they have not decided on a suitable technology that ensures factors such as availability, security, and integrity of information. Given the above factors and the characteristics of the problem, where there is a large number of financial and governmental organizations with the need to participate and validate together each step of the embargo process, the implementation of a centralized system would not be entirely efficient since its implementation involves additional costs and efforts. Achieving the required availability in a centralized system implies the use of replication of mechanisms in several servers in different geographical locations and with the need to implement mechanisms for their constant synchronization. In terms of how much security is needed in the centralized systems, there are users that have the ability to modify information without any restriction, giving opportunity to possible fraud that can compromise the integrity of the information. Considering what has been described, the objective of this article is to present a solution based on blockchain to reduce costs and increase the efficiency of the embargo process, as well as to improve collaboration between the entities involved in said process [13, 14].

Forthcoming in Sect. 2, we present the developed solution, explaining the design decisions and the architecture of the system followed with more details of the components of the system and their interaction. Finally, in Sect. 3, we present the conclusions and future actions that the team recommends be carried out.

2 Proposed Solution

2.1 Solution Approach

To solve the various problems associated with the embargoes notification process described above, we chose to design a pilot application developed in a virtual environment and then deployed to a private network. The proposed application allows a document associated with an embargo order to be published and distributed to a set of users with the necessary credentials to represent a receiving financial entity, which in turn can generate and record documents with answers for each ID or NIT listed within the garnishment notice [5].

The system has been designed so that each embargo notice, annex documents and response documents are associated and managed by their own metadata, as well as connected to the users of the system that manages it. The objective of the system is to use the potential of blockchain to propose a document management system that simplifies each of the stages of the process, allowing each task to be carried out in an efficient manner, reducing cost overruns and delays in the process [11, 12].

To make an adequate decision on which blockchain platform to use for development, different aspects were analyzed, including: (1) the nature of the blockchain, (2) the number of transactions and the traffic supported by the network, (3) the ease of development, (4) the deployment, and (5) the costs involved. Additionally, there is great convenience to using a private blockchain and a public one [2].

2.2 Public Blockchain vs Private Blockchain

Considering that a blockchain network can be divided into two clear models: the public blockchain implementation model, and the permitted or private blockchain model, a study was made of the advantages of each one, based on the infrastructure used by the different participants of the process.

Although initially the possibility of using a public blockchain network was considered, instead we decided to use a platform that would allow the implementation of a private blockchain for various reasons. In the first place, the proposed solution mainly seeks to manage user permissions by providing restricted and confidential access to the data stored within the blockchain. It is much more viable to implement within a private blockchain that is guided under the concept of privileges, than in a public use blockchain where in theory any user can connect to the network and access the information.

Secondly, the ability to adapt the storage form, structure and content of transactions based on the system’s own needs and the rules of the process provided by the implementation of a private blockchain was considered.

Another important aspect that was considered is related to the consensus algorithms within the network, where work or stake test algorithms are generally highlighted in public blockchain networks, which contribute a greater degree of control over the network on possible attacks, but they require participating nodes with a high computing capacity with the aim of being able to mine within the blockchain. In the field of private blockchain, these algorithms may vary depending on the needs and requirements of the network and the transactional system itself, implementing more efficient mechanisms in terms of computational resources for consensus among the different participating nodes, a situation that is important when considering the heterogeneous infrastructure that the participating institutions have [1, 3].

2.3 Selection of the Blockchain Platform

By adopting the private blockchain model for the development of the prototypes, the next step was focused on choosing a suitable platform among several available options. In this aspect, different options were considered, opting at the end for the Multichain platform.

Multichain is an open source platform with support for the development of private blockchains and oriented to financial transaction systems sponsored by a broad set of companies in the sector. In addition, through previous experimentation, it demonstrated a good ease of deployment adaptable to the architecture defined in the design of the prototypes.

Table 1 presents a comparison between some of the different blockchain options considered, including the comparison between Multichain with public-facing blockchains, among which are some well-known ones such as Bitcoin or Ethereum [6,7,8,9].

Table 1. Comparative table of blockchain platforms considered
Full size table

2.4 Architecture and Deployment

The pilot application was designed to work on a Web environment. At the architectural level it is possible to distinguish two main components: the client, in charge of interacting with the end users of the system; and the server, in charge of containing the logic to interact with the blockchain and attend to the different requests sent from the client. Both client and server are deployed in separate environments with similar hardware and software aspects, on servers running the Apache 2.4 version and supported on a GNU/Linux operating system in the Ubuntu version 16.04.

In Fig. 1 the main components of the system are presented and then a general description of their interaction is presented.

Fig. 1.
figure 1

System architecture

Full size image

An entity connects to the web application (ClientWebApplication) making a connection to the server by sending a request for registration or reading, the server sends this request to a node (Node 1, Node 2, …, Node N) which is responsible for registering in the blockchain, after this the blockchain is synchronized and all the participants are informed of the new record.

It is important to emphasize that the operation of the blockchain does not depend on any centralized database; the centralized database is used when reports are requested, and it is required to gather information from the blockchain.

Considering the architecture presented in Fig. 1, the client used the Java programming language and the JSF framework together with the MVC model. This component was organized in packages (see Fig. 2) where the facades package is in charge of making the connection with the server sending JSON requests to obtain or record information; the drivers package is responsible for communicating with the facades to obtain the necessary information and convert it into the types of data to be used. Finally, the Views use the controllers to obtain the necessary data. The package models make a representation of the information in the blockchain as a class and the package utilities are classes used for different purposes.

Fig. 2.
figure 2

Distribution of components to Client

Full size image

Regarding the server application (see Fig. 3), PHP was used. The implemented REST API is divided into two main directories; the first, called ‘logic’, are the files with the classes responsible for taking the requests, analyzing the validity of the data and applying the logic of the business for the registration and reading of a transaction or set of transactions structuring a response that can be sent to the client in the front-end. The second directory, called ‘cli-multichain’, contains a set of classes whose function is to allow the communication of the REST API with the multichain API, allowing to perform read and write operations in the blockchain.

Fig. 3.
figure 3

Server component distribution

Full size image

On the server in the ‘cli-multichain’ package there are two classes that have greater relevance, which are ‘Stub’ and ‘Client’. ‘Client’ is responsible for isolating details directly associated with the commands issued to the multichain API, allowing these operations to be done in a generic way and being very useful if you decide to change the blockchain platform. ‘Stub’ works as its complement and contains commands dependent only on the implementation of the API provided by multichain.

Figure 4 shows the source code of the function called ‘multichain’ contained in the ‘Stub’ class, which allows one to issue commands directly to the multichain API by specifying a host address, a port number, and a user with its respective password through which it is possible to connect to the ‘multichain daemon’.

Fig. 4.
figure 4

“Multichain” function code

Full size image

As a complement, the ‘multichain’ function is invoked by various functions contained in the ‘Client’ class, in Fig. 5, the sample ‘getDatosTransaccion’ function is taken as an example, which allows obtaining the metadata of a specific transaction identified by its transaction identifier or ‘txId’.

Fig. 5.
figure 5

Source code function “getDatosTransaccion”

Full size image

Internally within the function ‘getDatosTransaccion’ the ‘multichain’ function is invoked to specify the ‘getrawtransaction’ command proper to the multichain API, which queries and returns the metadata associated with the transaction with the specified ‘txId’. Once the metadata is obtained, these are converted from hexadecimal format to plain text, and are encoded in a JSON object, which is returned to the ‘logic’ package controllers, which add the final headers, encrypt it and return it to the client.

It is important to note that in the implementation of the REST API within the servers there are no components in charge of data storage in any relational database since all the record and reading of documents are handled directly according to the rules of storage in the blockchain. However, the solution uses a relational database that contains data that may be susceptible to being changed over time; for example, information associated with personal customer data and/or contact data between entities. It is considered that storing this data within the blockchain is inappropriate at the conceptual level.

With the proposed solution, a series of improvements are achieved during all stages of the embargo process. In the first place, the delivery times of the documents associated with notification and response of embargo requests would be greatly reduced given that these documents would no longer be issued physically and distributed by postal mail, and instead will be issued in digital form using blockchain as a support to distribute them to all the participants in the process through a network. In addition, implementing the proposed solution will exponentially reduce costs in the embargoes process. The costs associated with sending the documents by postal mail could be suppressed, as well as reducing the cost overruns generated by the fines incurred by the receiving financial entities by the untimely notification of the documents responding to the requests for embargoes [10].

The above benefits will also generate effective collaboration between all the organizations involved, optimizing the communication process between them, and directly benefiting the customers of financial institutions. For example, a client of two or more of these entities would no longer be affected by the execution of a compulsory seizure action from all financial entities where they have funds and would avoid the arduous process of requesting the reimbursement of their assets once this has been done. The problem is solved with the government entity that issued the order for embargo enforcement. This is possible because through the implementation of the system, organizations will have knowledge of the execution of embargo actions executed for each of their clients at any time during the process.

2.5 Roles and Permissions

Information in MultiChain is saved by means of Streams that enable a categorization of the information and a level of permissions for these categories. As such, the following roles are defined in the system for managing the respective permissions in the network [4]:

  • Sender: The sender features the following privileges: (1) “Connect”, which enables it to connect with other nodes and see the contents of the blockchain; (2) “Send”, which allows it to write information only in the Streams to which it is subscribed - in this case the sender is subscribed only to the “generated_documents” Stream and is thus permitted to upload information to this Stream only; and (3) “Create”, which permits it to create a Stream. Each time a document is uploaded, a Stream is created so that the responses of the receivers can be recorded there.

  • Receiver: The receiver has the privileges of “Connect” and of “Send” only in the Streams to which it can upload a response.

  • Administrator: The administrator has the option of granting and revoking all the permissions available in the network, such as “Connect”, “Create”, “Send” and “Mine”. The latter allows the selection of which nodes will be miners in the blockchain.

This system of permissions functions analogously to authentication, as is the case in BitCoin, generating a public key and a private key as follows:

  • Each node presents its identity as a public address in the list in which the permissions are defined. This list is contained by all the nodes in the network.

  • Each node verifies that the applicant’s address is on its own list of permissions, in order to ensure a consensus.

  • Each node sends a challenge message to the other party.

  • Each node returns a signature of the challenge message, which shows its ownership of the private key corresponding to the public address they presented.

  • If there is any irregularity in any of the nodes, the peer-to-peer connection will be aborted.

2.6 How Does It All Begin?

The miner of the first block, called the Genesis block, automatically receives all the privileges. This participant is in charge of managing all the privileges for the other participants. The privileges that are granted or revoked are recorded as a transaction to keep track of these activities. When there are more than two administrators in the blockchain and a change is required in the privileges of a participant in the role of administrator or miner, a consensus will be needed wherein all of the administrators approve the change.

When a new node is prepared to be part of the blockchain, this node saves both a public and a private key. The administrator subsequently gives connection permissions to the new node using its public key.

2.7 Encryption in Streams

To achieve confidentiality in the Streams, the data is encrypted before being stored in the blockchain. The password to read the encrypted data is only available to a subset of blockchain participants; the others cannot read it. This task can be carried out quite efficiently by using a combination of symmetric and asymmetric cryptography.

“The method makes use of three blockchain streams, whose purposes are as follows:

  • One stream, which we call pubkeys, is used by participants to distribute their public keys under the RSA public-key cryptography scheme.

  • A second stream, which we call items, is used to publish large pieces of data, each of which is encrypted using symmetric AES cryptography.

  • A third stream, which we call access, provides data access. For each participant who should see a piece of data, a stream entry is created which contains that data’s secret password, encrypted using that participant’s public key.” (taken from MultiChain whitepaper, see https://www.multichain.com/developers/stream-confidentiality) [6].

3 Conclusions

Through the implementation of the solution, we sought to present a cost-efficient alternative for the document management problems associated with the embargoes process in Colombia. Blockchain is an emerging technology that allows transparency at the level of transactions, adding features that improve the scalability, availability and integrity of data. The implemented solution allows another perspective with respect to traditional information systems usually based on a large database contained in a high-capacity server, transferring the system to a distributed database through a network point to point, where all the participants are responsible for the control and supervision of the data. This allows the system to have a higher level of availability since it will change from depending on the correct operation of a single central server, to the operation of a set of components made up of all the nodes that interact and relate to the blockchain.

Additionally, the characteristics of the blockchain networks allow for considerably improved aspects related to the security of the system and increase the availability of the proposed solution against different types of attacks such as DDoS since it does not have a single point of failure compared to the applications guided by conventional distributed architectures. Another improved aspect regarding the security of the system includes the integrity of the data, which are stored and verified by means of specific consensus mechanisms and, in theory, not modified or eliminated once written in the blockchain.

In the field of document management, it was found that the very nature of blockchain facilitates the availability and distribution of documents, as well as the monitoring and process of controlling changes in them, allowing each participant in the network to always obtain an accepted and revised version of the documents of interest in an efficient way, given that once a document is registered within the system it is immediately available to all interested parties who automatically seek to keep an updated copy of the blockchain. This is undoubtedly much more optimal than the physical distribution of documents by postal mail, or digitally using a conventional centralized system where the central server would usually be responsible for the extra task of sending update notifications to each of the clients, or on the contrary, clients saturate the server with requests for constant actualization. In addition, the use of blockchain allows the system not to depend solely on a large database that stores all the transactional information, having large workloads and consuming a large amount of space within the network equipment, which translates to a possible reduction of the costs of acquisition and maintenance of database servers in contrast to a traditional centralized document management system.

In contrast, databases store a smaller set of data associated with data mostly prone to change and/or be eliminated over time; these databases in turn should have a much simpler and more efficient relational structure that allows to optimize the processes of consultation and reading of the information.

One of the main objectives of the project team in the short term is to implement the proposed solution in a small set of entities as a pilot test in order to obtain feedback, find gaps, or possible needs not covered within the initial proposal. As a result, we will obtain a well-structured and robust solution that allows its generalized deployment in all the organizations involved in the process of embargoes in Colombia.