01
How counterparties enter the system.
KOTA accepts a counterparty record from either side of the relationship. Operators can self-register and apply externally. Banks can initiate a file on a counterparty they already work with, invite an operator to join, or run a programme-specific variant fitted to their context. The five paths converge on a single shape of structured record. Origin doesn't constrain what follows: the rigour of compilation, evaluation, and scoring runs the same regardless of how a counterparty arrived.
Operator System Registration
The operator visits the KOTA landing page and completes a three-step System Registration: personal details, organisation details (legal name, supply chain position, registration country, legal form), and a short readiness assessment. On submission, the operator gains immediate access, with no waiting on manual approval, no documents required at this stage.
Registration data flows directly into the operator's structured profile. The Readiness Assessment is a short pilot-validated question set that signals where the operator stands against banking-grade expectations before any formal application begins, surfacing useful context for the eventual reviewer without gating access.
From this point on, the operator has a workspace they own: a profile they can extend, a dashboard to track every counterparty engagement, and the foundation for everything that follows in the platform.
External Application
A registered operator opens the Stage 1 Application form for the bank of their choice. The form is the bank's, but the layout adapts to the operator's actor type: a cooperative submits cooperative documents; a licensed trader submits trader documents; an artisanal miner follows the individual identification path. Required documents render as a structured checklist with progress tracked at row level.
The same workflow covers both possible answers to the “is the organisation already a client of the bank?” question captured at registration. New applicants advance to Stage 2 evaluation on approval; self-declared existing clients have their relationship confirmed and pass directly into Stage 2 monitoring. The bank verifies the submission either way. The answer only changes what happens after approval.
On first submit, a sharing channel opens between operator and bank. Both sides see the application's state, the documents shared, and the role assigned for review. After submission the operator immediately unlocks the platform's full profile-building modules (Self-Assessment and Due Diligence), so motivated applicants can strengthen their file from day one rather than waiting on the bank's decision.
Bank-initiated Registration
Banks can also start a counterparty record from their side. The registration screen exposes two entry points. The first creates a record for a new applicant the bank wants to onboard, a three-step flow that ends in reviewer-approved transition to Stage 2. The second creates a record for a counterparty the bank has already vetted off-platform, a two-step flow that skips reviewer involvement and lands the record straight in evaluation.
The split exists because the two situations carry different review semantics. A new applicant has not yet been vetted, so the standard reviewer pathway applies. An existing client has been vetted already, sometimes for years; KOTA is the place their record now lives, not the place their initial vetting is being re-done. Both paths run on the same form structure, the same validation, and the same scoring inputs.
From this point both paths converge with the operator-initiated paths. Subsequent compilation, evaluation, and lifecycle workflows behave identically. The only place origin matters is in the audit trail.
Customer Invitation
When a bank has an internal record on a counterparty that lacks digital access, the bank can invite the operator to join KOTA at any point once the record has reached Stage 2. The invitation issues an account for the operator and grants them edit rights over the data the bank has already compiled.
From the operator's side the invitation arrives as an email with a registration link. On accepting, the operator inherits the bank's snapshot as their own starting point (partly compiled, ready for them to verify, extend, and share with the next counterparty). Custody passes cleanly: the bank keeps its independent copy for ongoing engagement, and the operator starts with their own working profile.
This is the platform-level expression of how data moves between accounts in KOTA. The mechanic is the same one that powers data sharing across every counterparty pair, just scoped here to the invitation moment.
Cooperative Onboarding
For aggregators consolidating cooperative production, KOTA offers a tenancy variant fitted to cooperative onboarding. The form set is trimmed to what cooperatives actually need; the actor-type dimension drops individual paths that don't apply; the role labels and reviewer model adapt to the aggregator's operational reality.
What stays constant is the methodology. The same scoring backbone, the same custody rules, the same structured profile, governed centrally by Datastake and inherited by every adopting party. Per-tenant variants of the same pattern are first-class on the platform, not bolt-on customisations.
The cooperative still owns its profile. The aggregator gets a record fitted to its programme. The operator can later engage a bank without rebuilding the file. The structured record travels with the operator across counterparties. That's the long-term compounding payoff.
02
Building the structured profile.
Once an operator is in the system, compilation is the patient work of turning operating reality into a defensible record. KOTA breaks that work into pieces an operator can finish, in plain language, at their own pace. Every field is explained in terms of the work the operator does on the ground, not in the language of a legal manual. Three modules carry the compilation load: the inheritance pathway for invited operators, the Self-Assessment for KYC and Management Systems, and the ongoing Due Diligence reporting surface.
Inheritance at Invited Registration
When an operator joins KOTA on a bank's invitation, the data the bank had already compiled flows into the operator's newly-created account as their own copy. The event is one-off, not a live link. Custody passes to the operator on submit; the bank keeps its independent copy for ongoing engagement.
This is how data starts on the operator side without the operator having to type it twice. The bank's diligent compilation pays off as the operator's working profile from the first session: fields pre-filled, documents attached, ready for the operator to verify and extend with information only they can provide.
The principle extends in both directions. Whenever data moves between parties in KOTA, the movement is a custody event: a new copy is created, not a link. Each party owns their copy from then on, with no live updates back to the source. This is what lets multiple counterparties engage the same operator without sharing a single database, and what lets each party run its own analysis on the data it holds.
Operator Self-Assessment
Self-Assessment is the structured compliance module operators use to compile the data banks evaluate. It is built around three groups of forms. KYC is the structured compliance profile, organised across the standard sections banks expect for identity verification, ownership structure, and operating context. Information already provided during Registration and Stage 1 pre-populates: nothing is entered twice. Additional Information sits alongside KYC for deployment-specific or non-standard captures (such as FATCA declarations for the TMB deployment), so the standard KYC profile stays consistent across deployments.
Management Systems covers five sub-assessments aligned to OECD Due Diligence Guidance Step 1: Supply Chain Policy, Internal Management Systems, Supply Chain Integrity, Supplier Engagement, and Grievance Mechanism. Each sub- assessment has its own completion tracking and progress bar. Indicators across the module roll up into a risk readiness radar visible to both the operator and the reviewing bank.
Every section is explained in plain language with guidance at every step. The operator saves progress and returns when documents are in hand. The platform tracks completion and flags what is still missing, so the operator always knows where they stand against the standard, and the reviewing bank gets a profile that's complete in context, defensible under review, and ready to engage the market.
Due Diligence and Ongoing Reporting
Where KYC captures whothe operator's trade partners and sites are, Due Diligence provides structured space to compile what happensacross them over time. It unlocks alongside Self-Assessment after Stage 1 submission and remains available throughout the operator's life on the platform, not an onboarding event but an ongoing reporting surface.
Five sub-modules carry the load. Trade Partners expands on the basic identification captured in KYC with commercial detail about each buyer, supplier, and intermediary. Operating Sites extends KYC location data with mine, processing, and warehouse specifics. Activities lets the operator log inspections, audits, and operational events as they happen. Incidents captures reported events, disputes, and compliance moments in a way that survives review. Testimonials carries third- party attestations and references.
Each new entry strengthens the operator's case for compliance and the bank's case for engagement. New information flows into the operator's profile, becomes visible in the bank's consolidated analysis, and feeds the continuously recalculated score, so the relationship doesn't freeze at onboarding. Information stays current as the operation runs.
03
Scoring and decisions banks can defend.
Evaluation turns a compiled record into a counterparty decision the bank can defend. Three workflows govern this stage: how the bank adopts operator data as its own copy, how Stage 1 review distributes responsibility across three roles, and how Stage 2 evaluation derives a scored, rated outcome from the structured profile. The Algorithmic Stakeholder Evaluation methodology sits behind the score: deterministic, evidence-linked, and adjustable to the bank's policy.
Adopting Operator Data
When a bank receives an operator's application, the bank can adopt the operator's compiled data as its own copy. The custody event is one-off, not a live link. Banks own their copies independently and remain in full control of what they hold. Updates on the operator's side don't silently change the bank's view of the operator.
This is what lets multiple banks engage the same operator without sharing a central database. Each bank's record is its own, sitting under its tenancy, governed by its permissions, scored against its policy. The platform provides the structured form and the methodology; the bank provides the decision.
Operationally, adoption is exposed as part of the data flow on Stage 1 form completion. Where the operator's profile already carries a value or document the form needs, the field pre-fills with the operator's submission; the bank's editor verifies, adjusts where needed, and adopts on submit.
Stage 1 Bank Review
The Stage 1 application lands with three explicit roles. The Editor populates and prepares the record. The Custodian submits it for review once ready. The Reviewer decides: approve, decline, or return for completion, with audit-grade gating at each step. A single user may hold more than one role, which is common in smaller teams.
Notification routing follows the registration origin. Externally-initiated submissions alert the operator and the reviewer pool together. Internally-initiated applicant records alert the custodian who created them. Internally-initiated existing-client records skip the reviewer entirely and produce a single notification on submit. The bank already vetted the counterparty, so there is no claim to review.
A Stage 1 review produces an outcome the bank can defend: identified counterparty, structured documentation, completeness verified, and a record ready to flow into Stage 2 evaluation. If declined, the operator can edit and resubmit; if returned for completion, the missing pieces are flagged at row level so the operator knows exactly what's outstanding.
Stage 2 Bank Evaluation
Stage 2 runs through the Customer Summary: the consolidated view that pulls together Self-Assessment data, documentation, Due Diligence submissions, anything the bank has compiled on its own, and any third-party information. From a single screen the reviewer sees the structured record, the algorithmic score, and the supporting evidence chain.
The score itself is produced by Algorithmic Stakeholder Evaluation, a Datastake innovation. It's deterministic and transparent: every score traces back to the underlying data, and the same inputs always produce the same score, with no probabilistic or black-box modelling. Each component carries an explicit weight tied to inspectable evidence. The methodology ships ready to use and is fully adjustable: banks reweight components, tighten thresholds, fold in their own checks. The bank's credit policy still owns the decision; the score is the input it can stand behind under regulatory scrutiny.
On the rating layer, the bank applies its own A+ to E scale (or its equivalent) on top of the composite score. The rating determines which services the customer can access: accounts, financing tenors, due diligence frequency. Service-tier outcomes are bank policy; KOTA surfaces the score, the rating, and the supporting evidence, leaving the service-access mapping to the bank. Reviewers may override the calculated rating on a per-customer basis where internal considerations warrant it.
04
Keeping the record current and portable.
Onboarding is not a moment. Lifecycle workflows handle the parts of a counterparty relationship that come after the first decision: risk-driven state changes that reflect operating reality, and the reuse of structured data across the operator's wider counterparty engagements. Together they keep the bank's view of the operator current and the operator's investment in compiling data portable.
Customer Suspension
Risk doesn't stay frozen at onboarding. A reviewer can suspend an active customer at any time from the Customer Summary. Suspension pauses information sharing between the customer and the bank, locks the bank's ongoing data compilation on that customer, and surfaces a clear Suspended indicator across every list and review view where the customer appears.
The action is reserved to the reviewer role. It's a decision-grade state change with audit consequences, not a routine edit. The platform records the actor, the timestamp, and the reason. Past records and prior decisions stay intact; historical compilation isn't deleted, just frozen.
Suspension is reversible. When the underlying concern resolves (sanctions cleared, a documentation gap closed, a flagged incident investigated), the reviewer can reinstate the customer, resuming data flow and unlocking compilation without rebuilding the record from scratch.
Cross-Service Data Reuse
An operator who has compiled a profile for one counterparty can apply to a second with a single submission. The structured data pre-fills the new application; Stage 1 fields populate from the existing profile, documents attach with provenance preserved, only the fields specific to the new counterparty need fresh attention. The operator reviews, refreshes where needed, and submits, without re-compiling from scratch.
This is the operator-side compounding effect that makes sustained KOTA use worth it. The work an operator invests once pays off on every subsequent counterparty engagement. As two counterparties' requirement sets diverge over time, the pre-fill ratio reduces, but the principle stays: the structured profile is the operator's compounding investment, and KOTA pays it back on every application.
From the bank's side, the mechanic is invisible. Each bank receives its own copy of the relevant fields and documents, scoped to what the operator has chosen to share. No shared database, no live link between counterparties, no cross-tenant visibility of one bank's data by another. Each engagement is sovereign even as the operator's file compounds.
05
Reading across siloed sources.
The sector's information has lived in disconnected silos for decades: bank files, audit reports, scheme databases, public registers, civil-society reporting, the operator's own compilations. Triangulation workflows let banks pull from those sources and assemble subjects of interest outside the formal application path, with provenance preserved every step of the way.
Find Data
Find Data is the bank's surface for enriching a customer profile from external sources: public registers, verification services, audit reports, civil-society reporting, and other applications in the Datastake ecosystem. From within a Customer Summary, bank personnel trigger a query and adopt the findings into the customer record on their own terms.
Results surface as additional information sources in the customer's consolidated analysis, with provenance preserved. Each adopted finding is logged with its source, its adoption timestamp, and the role of the user who adopted it, so what's added survives audit and remains traceable.
Queries map to structured intents: triangulate ultimate beneficial ownership, validate data reliability, discover trade and location links between known counterparties, rather than free-text search. The bank decides which sources to interrogate and which findings to adopt.
Add Prospect
Some counterparties start as individuals: an artisanal miner, a sole trader, a person of interest to ongoing monitoring. Add Prospect creates a standalone individual subject linked to the bank's portfolio without requiring a formal application yet. The bank's editor or custodian populates what is known; the record sits inside the bank's tenancy and feeds into triangulation across the wider portfolio.
The prospect can later be developed into a full operator record, linked to an existing cooperative or company, or shared with another counterparty as the engagement matures.
Together with Find Data, Add Prospect closes the loop on the bank's information work. The bank doesn't only wait for operators to compile and submit. It can build subjects on its own initiative, triangulate them against external sources, and tie them into the broader counterparty network when the right relationship emerges.