Skip to content

Overview

Traceability To Plantation (TTP) application for the Malaysian Palm Oil Industry. Visit the application here.

Each entity in the supply chain, who has MPOB License number, can register for an account to upload Excel files onto the platform to visualize their upstream suppliers.

The uploaded data is matched against the MSPO database using MPOB License number.

  • Matched entities with GPS coordinates are rendered on Google Maps
  • Unmatched entities are held in suspense until official data is available

Current challenges

When a buyer requests for traceability data, that request gets passed up the supply chain. For example, a refinery purchasing CPKO will request data on their suppliers from crushers. The crusher then has to request and consolidate data from his supplying mills, and the mills in turn requests the data from his estates, dealers and smallholders.

Non-standard data

User-submitted data lacks consistency and standardization across the supply chain. Each entity (e.g., supplier, manufacturer, distributor) uses its own internal codes to identify trading partners and maintains its own version of key information. As a result:

Entity identifiers (codes, names) differ between parties. Address records are recorded in varying formats. GPS coordinates for the same physical location may differ or be missing.

This leads to multiple, non-standard copies of the same core data being held by different entities, making integration, reconciliation, and traceability difficult.

No direct relationship with upstream suppliers

Downstream entities (e.g., the crusher) are required to consolidate data from all upstream suppliers in the mill’s supply chain. However, they lack direct business relationships with suppliers beyond their immediate (direct) suppliers.

This absence of a contractual or operational relationship makes it difficult to request, verify, or obtain accurate data from indirect upstream parties, complicating compliance and traceability efforts.

Duplicate data collection across suppliers

Mills often supply multiple downstream buyers (e.g., crushers or refineries). Each buyer independently requests the same upstream data, causing repeated collection efforts.

Example: A refinery sourcing CPKO from 10 crushers must gather overlapping supplier data 10 times, leading to redundancy, extra workload, and inconsistent records.

Slow, error-prone, fragmented, inefficient and messy periodic data collection

Data must be collected periodically (typically annually), not as a one-off exercise, because supplier relationships are dynamic—mills and upstream suppliers change frequently (e.g., a buyer may source from different mills month-to-month).

The current process is highly inefficient: requests are sent via email or WhatsApp, and data is returned in non-standardized Excel files with inconsistent columns. The requester must manually consolidate, clean, and standardize this data before passing it to the end buyer, creating significant delays and error risks.

How the app solves these problems

The app relies on MPOB License (mandatory to operate in the palm oil industry) to match entities against the MSPO database.

Standardized Data

All MSPO-certified entities are refreshed on a schedule, and the database contains all the requisite information such as address, latitude, longitude.

The user only needs to upload (4) columns of data:

  1. mpob_id - MPOB License Number. Required to operate in the palm oil industry
  2. entity_type
    • estate
    • ffb_dealer
    • mill
    • smallholder
    • crusher
    • biodiesel
    • oleochemical
    • refinery
  3. entity_name - Included identifier
  4. quantity (%) - Breakdown of supply by percentage

On uploading an Excel file, the app will look up the mpob_id in the database and return the address and GPS co-ordinates.

If the mpob_id does not yet exist in the database (for example, FFB Dealers), the rows of data are held in suspense until the data is officially available from the MSPO website.

Single hop design

Each entity in the supply chain only needs to upload their data once, from their direct suppliers

For example, the mill's upstream supply typically looks like the following:

flowchart TB
  Mill((Mill))
  Crusher((Crusher))

  Smallholder[Smallholder] -->|3 hop| Dealer

  Estate[Estate] -->|2 hop| Mill
  Dealer[Dealer] -->|2 hop| Mill
  SmallholderDirect[Smallholder] -->|2 hop| Mill

  Mill -->|1 hop| Crusher

The crusher needs to collect the data through 3 hops from his indirect suppliers.

With the new file upload structure, each entity in the supply chain only needs to be concerned with their direct suppliers (single hop).

  • Dealer
flowchart TB
  Dealer((Dealer))

  Smallholder1[Smallholder] -->|direct| Dealer
  Smallholder2[Smallholder] -->|direct| Dealer
  • Mill
flowchart TB
  Mill((Mill))

  Estate[Estate] -->|direct| Mill
  Dealer[Dealer] -->|direct| Mill
  SmallholderDirect[Smallholder] -->|direct| Mill
  • Crusher
flowchart TB
  Mill((Mill))
  Crusher((Crusher))

  Mill[Mill] --> |direct| Crusher

This design solves the duplication problem as the app will automatically link all upstream suppliers by mpob_id for a given time period (currently annual).

Easy for users - familiar file format Excel

The app caters to non-technical users who are familiar with Excel files and requires no change in existing user behavior, with an ultra simple 4-column requirement.

They can simply filter their weighbridge system by Year, export their data into Excel, and upload the Excel file onto the platform to immediately visualize their entities on Google Maps.

Automated data collection process

The data collection process can be further automated by exposing an authenticated API endpoint and allowing users to push their weighbridge data directly to the API at regular intervals.

sequenceDiagram
  autonumber
  participant Job as Scheduled Script
  participant WB as Weighbridge Database
  participant API as Authenticated API Endpoint

  Note right of Job: Holds DB/API credentials

  loop Scheduled interval (e.g. daily)
    Job->>WB: SQL aggregate by time window
    WB-->>Job: Aggregated records
    Job->>API: POST JSON (Bearer token)
    API-->>Job: 200 OK (ingested)
  end