The key role of Fisheries Information Systems

Following on my post on the Ideal Processing State set up for a CDS, I follow here on the key role Centralised Fisheries Information Systems (FIS), based on what I wrote in our recent FAO book for a CDS and that I adapted a bit for the Pacific context for a report I have done for FFA.

Before coding there is always planning and paper

There are numerous advantages in a complete and effective centralised fisheries information system for a regional fishery organization in terms of MCS, science, management, economic intelligence, assets management just to name a few. In the context of PSM in general and CDS in particular, the effectiveness of a FIS is fundamental, yet it has to cater to a specific set of needs, mostly not available in the present systems.

Specific FIS requirements for PSM and CDS

For any regional fisheries organizations, the specific set of needs to be covered refers to traceability and catch accountancy in particular in countries that are port and processing states. 

The FIS should be able to incorporate three basic functions in terms of supporting CDS: 

1. ensuring that no illegal products enter the territory; 
2. providing a national traceability system that rapidly identifies fraudulent economic operators by means of detected mass-balance inconsistencies; and 
3. validating trade certificates covering consignments exported from the territory.

Integrations of Landing controls

Port /processing states have a duty to ensure that no illegal product in any form is imported, whether landed as catch or imported commercially. 

When products are imported into a processing state, it must ensure that data relating to the consignment, products and certificates are recorded in the CDS.

Such systems enable processing states to identify sources of mass-balance inconsistencies detected by CDS through certificates when attempts are made to ship more product out of a country than was imported. In the absence of centralised traceability systems, and depending on the size of the processing industry, identification of fraudulent operators in national supply chains systems could be impossible.

Once products are cleared to enter a port / processing state, the need is to trace: i) buyers of products covered by particular certificates; ii) product distribution and transformation into value-added goods; and iii) the consignments in which they are re-exported. The ultimate aim is to ensure that the transactions tally to account for the entire amount of product.

Six KDEs (Key Data Elements) constitute the core data of a national traceability system:

1. product source – seller and previous owner of the product;
2. product destination – buyer and new owner of the product;
3. species;
4. volume;
5. product form; and
6. certificate number.

Of course, in port states where transshipments are the norm, mass balance is relatively simple as most “fish in” accounts for “fish out” in one or more carriers. If the product is landed for containerization and direct exports only, a similar scenario applies. However, if the unload is separated in different batches according to size, weight, ecolabelling status and from then on different “batches” have very different destinies. The FIS needs to account for these scenarios

A batch of products changing hands may be covered by more than one certificate, but the information to be recorded in the traceability system is certificate-specific. If, for example, a batch containing product from three certificates has been mixed and is being sold, the information to be logged for the transaction must still establish three individual certificate-specific records – not a single new record that would necessitate a new certificate number.

Because people often think in terms of product batches and consignments rather than product volume that may be split or mixed, it is essential to clarify whether the national system traces batches of product through the supply chain and hence ensures their integrity. There are many reasons why batches have an important role in processing.

But because landings under particular certificates may consist of different species and different product sizes, a landed batch may immediately be broken up among several buyers – even though it is covered by the same certificate. And as product moves through the supply chain, “sub-batches” may be further distributed among economic operators. At the other end of the supply chain, semi-processed or processed goods may be mixed with product originating from other certificates, thereby merging several initial batches into a new batch for export certification.

Any traceability system is concerned with:

1. the volume and form in which a particular species enters the supply chain under a certificate;
2. the volume and form of that species exiting the supply chain under that certificate; and
3. knowing every stop through which the different volumes and forms have moved within the supply chain.

Hence traceability systems are programmed to trace the volumes of particular species and products rather than batches that enter supply chains under particular certificate numbers. It can follow these volumes as they are split or merged any number of times, and it can follow changes of form and processing losses affecting the species concerned. Every time a batch moves forward in a supply chain, the transaction, original certificate numbers, species, volume and form are recorded and deducted from the lot of certified products that originally entered the same supply chain stop.

Points in the supply chain where integrated tracing is necessary

Traceability records are created at the beginning and end of any supply chain stop.

Economic operators in national supply chains acquire a batch of product, which may be covered by a single certificate or several, and must record the products, volumes, forms and certificate numbers. This record identifies the source of the products, and must match the exit record logged by the previous economic operator. Such a record may be seen as a “product account” owned by the buying establishment, which can now process and sell or export the products. These will be logged again in the same traceability system at exit.

System attributes

Certain attributes of national traceability systems determine their effectiveness and whether they will be accepted by the industry. They must be:

• user-friendly, simple and intuitive so that its users quickly learn to operate them effectively; record-keeping may be based on official templates and guidance set out in a user manual; these may be in online formats;
• results oriented with clear statements of expected results, and all functions should serve these results; this ensures that the system will not become complicated and hence prone to failure;
• tamper proof, providing a high level of data security, especially in online systems; the fishing industry is particularly sensitive with regard to commercial records, which must remain confidential; and
• grounded in legislation so that sanctions can be enforced in cases of noncompliance; in the absence of a legal foundation, non-compliance cannot be sanctioned and the system will fail.  

An official online platform in which operators and authorities record their data is always the prefered option. One advantage is that it does not require specific software to be set up at the operator level, so any operator can access the system from a standard computer with an online connection, create a user profile and start using it. Another advantage is that upgrades are greatly facilitated. Electronic platforms largely eliminate the need for paper communications between a competent authority and the private sector because all data can be handled electronically. Such platforms can also serve to issue trade certificates, which is especially useful if the CDS has no electronic system for doing so.

At least two user groups are defined in electronic platforms: i) private-sector operators who input data and submit requests for the validation of certificates; and ii) competent authorities, who exercise oversight, analyse data and validate certificates.

Functions of electronic platforms – user groups

Electronic platforms are more versatile and more powerful than simple record-keeping solutions. They handle data from landing, importation, distribution, ownership and exportation centrally in near-real time, thereby enabling competent authorities to track how much product is entering a country, who acquires it, how much a company holds in its inventory, what is being processed into what and how much is being exported.

For economic operators, the following functions are essential:

• Login and system overview. A user ID must be required to access the system, at which point an initial page gives an overview of pending submissions and requests and validations by business partners and the competent authority. From here operators can access all functions of the system.
• Product entry and creation of product accounts. Operators must create product accounts that link product entry to premises with the covering certificates. Supporting documents such as landing or import declarations, catch certificates and invoices must be uploaded: competent authorities will validate these and authorize the creation of the product account. All processing runs and product sales are then deducted from such accounts until depletion. Busy operators will use large numbers of such product accounts.
• Product exit, subtraction from the product account and certification. Operators can generate products and prepare them for exit from their premises with trade certificates mandated in CDS. Operators can sell products in the same form or in pre-processed form to other economic operators in business-to business transactions in the same territory and market, or they can export processed products, or they can sell the obtained end-products for domestic consumption in the same territory. The details of such processing runs are logged into the system, providing product account number, species, form, volume used and volume resulting. The resulting product is deducted from the product account. These options are detailed below:
  • Business-to-business transactions. Buyers log acquired raw materials in the system, uploading copies of invoices, catch certificates and original product account numbers, which are shown in invoices. Sellers see a request to validate a sale, and the products are deducted from the sellers’ product account; a new product account is created for the buyer. For a transaction of this kind no certificate is generated or validated and there is no need for validation by competent authorities. The platform ensures the integrity of buyer-to-buyer transactions, and accurate debiting and crediting of the respective product accounts.
  • Export transactions. Processing information is logged by operators with reference to the source product accounts for the raw materials. This is based on consignments being prepared for exportation rather than individual processing runs. For every product account operators log volumes, forms and species processed and the amounts of resulting product obtained. The system can then calculate and log processing yields, and signal if a yield anomaly is detected. Supporting documents – bills of lading, export declarations and commercial invoices are uploaded in support of submissions, which result in requests for trade certificate validation by the competent authority. When this is done, operators can pick up a printed, signed and stamped original at a designated office. 
  • Domestic market transactions. The system records sales of products into a domestic market, either directly – which is unusual – or through wholesalers or retailers. This is also logged by consignment and is entered in the same way as a business-to-business transaction: buyers input the data and have them validated on the platform by the seller. These records close the loop at the domestic end-market blind spot, but they require wholesalers and retailers to participate in the system. These transactions require validation by competent authorities and result in “inward trade” certificates issued to domestic buyers. Such certificates are not mandated in CDS, but should be mandated in national CDS-supporting traceability mechanisms to ensuring that all product volumes leaving premises are traceable and reconcilable.
• Product account balance. The system must automatically compute the remaining balances in product accounts until depletion of individual accounts; a query function should be available (see next).
• Queries. The system should enable any operator to query all aspects of acquired CDS-covered products. This must cover product in storage or processed at a facility and must include past production runs, shipped consignments and product account balance status by species, form and certificate numbers to provide a full overview.
• Error correction. The system must enable operators to correct data errors.105 Operators must be able to correct data that are as yet un-validated, and if data have already been validated, operators must be able to correct them with the agreement of the validating counterpart.

For competent authorities, the following functions must be available:

• Login and system overview. Competent authorities must be able to access the system. An initial screen should show all pending validation requests, their status in case several users are simultaneously accessing the platform, and system-generated alarms. Various options should be available to enable users to navigate to functions relating, for example, to queries and blocking documents.
• Validation of actions and requests. The first function of the system is to forward validation requests from economic operators to the relevant competent authority. The three groups are: i) validation for product account creations such as buyer product entries covered by CDS certificates; ii) validation of trade certificates; and iii) validation of error correction requests. The platform enables competent authorities to view supporting documents so that verifications can be undertaken before validation is granted.
• Queries. This powerful function enables competent authorities to view the product accounts, individually or in groups, of individual economic operators, clusters or an entire national sector. Queries must make relevant information accessible to competent authorities so that they can monitor domains of interest and historical data. Interfaces can be designed that enable users to make queries that combine any type of stored data.
• Document blocking. This important feature enables competent authorities to suspend or block documents such as product accounts or trade certificates submitted for validation. Suspension occurs when an inspection is ordered to ensure that products cannot legally be exported. Blocking occurs when products in a product account or draft trade certificate are denied movement along a supply chain because fraud has been detected. Without such a mechanism competent authorities would be unable to use the traceability platform for law enforcement purposes, and could only rely on for information.

Functions of the electronic platform – calculation routines and alarms

The platform will be designed to execute a number of functions. The most important are:

• Automated product-flow monitoring. The mandated data-logging routines of economic operators for sequential handling of products along national supply chains feed into the automated product-flow monitoring process. Product is credited to a buyer’s account during an acquisition transaction and is deducted from the same account when it is sold on to the next buyer. Inconsistencies can be detected immediately, just as CDS detect inconsistencies between importation and exportation. The platform monitors the product flows of individual economic operators and detects inconsistencies at this level. The platform does not have to establish the integrity of transactions involving several operators or certificates. If successive domestic transactions relating to a specific certificate are satisfactory, the balance between entry and exit at the country level is also satisfactory.
• Processing yields. The system must be capable of capturing all processing yields on the basis of volume declarations for product form “in” and product form “out”.  The platform then establishes a database of processing yields based on species, original form, resulting form and yield factor. Statistical analysis then establishes the related mean processing yields/losses. Yield factors will fluctuate around the mean according to product quality, seasonal fluctuations of species condition indexes and the skill of factory workers to produce a normal distribution around the mean. The system can generate an alarm when a production run submitted for certification exceeds the mean by a given number of standard deviations.
• Automated alarms. The system must trigger alarms when anomalous data are logged into the system. Alarms must primarily alert economic operators: if they try to log a transaction that is inconsistent – more product than available being input for sale, for example – they must be able to rectify the situation. In cases of mass-balance inconsistency, the system must be able to reject the submission and automatically enforce the mass-balance integrity rule.108 In cases of excessive processing yields, users may decide whether they will be justified at a later stage in case of queries by competent authorities. If erroneous data input leads to automated submission denial, the need for intervention by competent authorities is reduced substantially. Operators must ensure that their bookkeeping, inventory management and data submission are accurate.