Introduction
This is the first in a short series of articles aimed at exploring the issues faced by those commissioning a system to automate physical deliveries in the international commodity trade-market; i.e. to provide a trusted, secure system which is based on a legally binding method by which a buyer may receive goods from a seller, in locations where international trade is respected. Sounds simple, and something that occurs innumerably every day throughout the world of international trade, however, and as an example, because something happens frequently without issue it does not mean that the security is proven. Parties can trade with each other for years on the basis of trust but in the event of say, a default, the assumptions made by the buyer about the legal status of a document purporting to give title to the goods may not be all that he had assumed it had prior to the default.
It should be understood that this series is not about the specifics of a delivery system but looks at the background issues that often remain unaddressed during the critical moment of the inception of a project or market initiative.
Discovering the detail
Is it the role of the software-provider engaged to design a delivery system to answer all sorts of trade-related questions? No, it is not; but it is the role of the responsible software-provider to ask some fundamental questions at this juncture, the design stage of a system, when significant changes may be made. This is particularly true when dealing with systems designed to be overseen by a third party, for example a futures exchange, as the robustness of the system may be tested by the users who would not have commissioned the system and may even be seeking to find an advantage through any defect. It is therefore important that the chosen system provider has the experience and expertise to ask pertinent questions on the overall operation that underlies the system itself. When the objective of a project is to drive a car from A to B, the design specified to build a car may be ideal if there is a road from A to B, but that assumes that first, a road exists, and second, that it suits the car to be designed. The car may be the fastest thing on four wheels but may not reach half way to point B because of the state of the road. In this analogy, it helps if the software provider has the essential expertise not only of car design but has civil engineering abilities as well.
Dealing with legacy issues
Most software projects are to emulate a set of processes that have been developed over a number of years. Inevitably over this time the system, manual or otherwise, will have a number of legacy issues or “technical debt”. For example, the basis on which the operation was originally designed may change. These changes may have consequences at a legal level which may not be at a national level, they may be by-laws affecting goods located in certain ports, or indeed the terms under which certain essential companies in the delivery process are prepared to operate. These inevitable changes over time may compromise a system that was sound on commission, but over time may have altered affecting the legal status of the delivery. The effect of these changes is often akin to icebergs, something small and just visible on the surface, but represent a huge danger lurking below. Like an iceberg, it innocently floats along, its true size and danger only becoming evident to the unwary ship when it is too late. Another example of legacy issues concerns the mode of handling certain goods, these have altered in order to ease handling and storage and to comply with health and safety requirements. The question is whether the system is able to reflect these new modes of handling? A seemingly simple change to a system may have profound repercussions, not only to the system under construction but also to others that may rely on it. For example, one simple, well-publicised change to a contract size made on an exchange delivery system meant that a significant user was unable to use that contract for nearly a year after the change came into force as they were unable to adapt their own software.
What needs to be answered?
- Legal
In any system there are some fundamental tenets that should be observed. The first is that the system is able to operate within an accepted legal framework. This is not as simple as it sounds as in this case we are talking about operating internationally. It is likely that the system will be faced with the conflict of laws; for example the buyer and seller may be in two separate countries, each with its own legal system; the goods lying in a third country, with a warehouse keeper that states they operate under laws of a fourth, and the sales contract subject to the laws of a fifth, different country. Potentially difficult to resolve in the event of a dispute, however the practical answer is to reduce the legal issues as much as possible and bring clarity in contract terms and reflected in the delivery system so that parties understand their respective responsibilities. Will this answer everything? Unknown situations will always arise making certainty impossible, but by addressing these issues it will provide more confidence to those using the system. Is it the role of the software designer to answer these questions? Again no, but the system provider being made aware of the issues means that the right questions are asked at an opportune moment in order for the those commissioning the system to consider relevant contract changes.
- Conflicts of interest
In the pursuit of profit, many legacy issues have occurred in the terms of delivery, particularly those of futures exchanges. It is in the terms of delivery where the value of the contract is truly established. In some cases the terms of delivery have debilitated the contract they exist to serve. These conflicts often come about as innocently as a falling snowflake, but after time, with more snowflakes compacted and the glacier formed, effectively the damage is done; eventually when the glacier meets the sea and the iceberg formed, it will successfully block the passage of free trade. This is such a profound issue that it will be explored in more depth in a later article.
- Maintaining integrity
Software design, and the contractual terms it is reflecting, can enhance the integrity of what occurs, either contractually or physically. Naturally all involved in designing a system will expect the integrity to exist, but checks and balances brought in can do much to improve what is stated in the contract. We now live in a different world to that of a few years ago; for food goods in particular, preservation of identity of cargo is no longer a nice thing to have but fast becoming a requirement; what check is there on the quality of those goods? What surety exists on the analysis? The challenge is to implement the requirement of maintaining integrity whilst keeping additional costs to a minimum, which brings us on to the fourth point.
- Reducing friction within the system
Implementing the design of a delivery system allows the opportunity to free up some of the blockages that have developed over the years, again usually stemming from legacy issues. When dealing with legacy issues it is vital to understand why things are done in a particular way. For example, it may seem archaic that old Fred in Admin makes a handwritten list of warehouse warrants that he, and only he, uses to check off warrants that are sent to the warehousekeepers. Actually, it may be that this is the only check that occurs and that Fred, having mislaid a warrant in 1988, developed his private list as a way of dealing with the problem because the cost of dealing with the issue formally was, at the time, prohibitive. And Management may think that adequate progress has occurred when Fred is persuaded to make his list on a spreadsheet… Usually the friction encountered involves people and what they have to do in order to process something in the system, so reducing this to a minimum whilst maintaining the integrity is the job of the system provider.
- Security and flexibility
Any system has to be secure, that is a given. The challenge is to provide the security but allow for flexibility, either from inception in terms of data download and upload, but also for system changes in the future. No matter how good the system was on commission there will be changes required going forward. The challenge is to be aware, not of what is coming, because that needs to be addressed as a matter of course, but to allow the system to be as flexible as possible in the event of unknown change. Some changes may be so fundamental that an easy (therefore cheap) change is not possible, however others should be straightforward. For example, it may be the current requirement that the system only needs to operate for goods lying in one country. Nevertheless, a software provider should allow for the expansion of that requirement for deliveries elsewhere, so that the questions of, for example, bonded warehouses, duties paid etc. are easily catered.
So, where to start? Often the common refrain is: “We want the system to copy what we have to do physically”, and, as described above, one that an adept but unthinking systems analyst will be able to document and have the system built to the eventual and likely dissatisfaction of the user(s). The commissioning of a new system provides an ideal opportunity to sit down and question every part of what occurs – physically in the warehouse or storage location as well as what the system itself is reflecting in the office. And it is to the warehouse that provides a good place to start the questions.
About the author
Robin Dand is now in the fifth decade of working in the commodities market. He specialised in the cocoa market and softs in general but also oversaw the administration of a LME Ring Dealing member. In softs, he has experience in cocoa, robusta coffee and sugar, both as an independent supervisor and in the contract development department at NYSE Liffe. His specific expertise lies with the physical delivery of soft commodities, including the quality issues of those goods. He also devised a system to offer Exchange clients Pre-Shipment Grading for coffee in Vietnam. As an independent authority on Cocoa and Robusta Coffee he runs Robin Dand Commodities Ltd. and has recently been working as Registrar for the Chicago Mercantile Exchange Europe, overseeing the quality assessment and delivery of their cocoa futures.
Robin Dand has written two books on commodities; “Cocoa: a Shipper’s Guide” and “The International Cocoa Trade” first published in 1991 and now in its third edition; as well as contributing to magazine articles. He is also a member of the Technical Committee of Cocoa Research UK. Apart from his family and soft commodities, his passions are Cricket and Olympic Trap Shooting at which he has represented England five times.
