White-label
Your brand. Your clients. Our rails.
Run a trade finance programme under your own name on infrastructure that already works, with the onboarding, the compliance layer, the document checks and the audit trail included.
Weeks to a live programme, against a two-year internal build.
The build-or-buy question
The demo is three months. The rest is two years.
Most institutions that decide to build trade finance software get a convincing prototype quickly. What follows is the part nobody scoped: identity checks across jurisdictions, a screening provider wired in and kept running after onboarding, document extraction that survives real paperwork, a process engine that does not lose its place when a customer goes quiet for a week, and an audit trail an examiner will accept.
None of that is interesting, none of it differentiates you, and all of it has to be right. It is also where internal builds die, usually around month fourteen, with a working origination form and no compliance story.
White-labelling inverts the order. You start with the boring layer finished and spend your effort on the part that is actually yours: the product, the pricing, the client relationships and the credit view.
- Onboarding, document checks and provider-backed screening already wired
- Your brand, domain and palette on every client-facing surface
- Your credit policy and pricing, not ours
Getting live
Four stages, measured in weeks.
The sequence is deliberately front-loaded: the decisions that are expensive to change come first.
- 01
Scope the programme
Which products, which client segments, which corridors, and the credit and eligibility rules. This is a workshop with your credit and operations people, not a form.
- 02
Configure the journey
Your onboarding process is arranged as stages with owners, deadlines and gates, and different routes for different client types. Configuration, not development.
- 03
Brand and connect
Logo, palette and domain applied to the client portal. Integrations wired to your core systems, and your own credentials used for any external checks you already pay for.
- 04
Pilot, then open
Run a cohort of real clients end to end, tune the journey against what actually happened, then open it up. Your team is trained on the tool they will live in.
What deployment involves
- Weeks to live
- For a configured programme with a pilot cohort
- Row level
- Tenant isolation, enforced by the database
- Your credentials
- For external checks you already have contracts for
- API first
- Every surface has an interface behind it
Timelines depend on the products in scope, the integrations required, and your own credit and compliance sign-off.
How tenancy works
One back end. Separate books.
Each programme, brand or client book is its own tenant. They share the engine and nothing else: isolation is enforced underneath the application, so a query that forgets its scope returns nothing rather than a neighbour's data.
- Your retail programme Your brand, your domain
- Your institutional book Separate policy and limits
- A partner's programme Their brand, your back end
Shared engine Process orchestration · onboarding · document AI · screening · audit trail
Administering three programmes should not mean operating three systems.
What you control
Yours, ours, and the line between.
The split matters more than the feature list. These are the things that stay under your control.
- 01 The brand
- Logo, palette, typography and domain on the client portal and outbound email. Your clients see your company, not ours.
- 02 The credit policy
- Eligibility, limits, concentration rules and approval hierarchy are yours to set and change.
- 03 The process
- Which steps exist, who owns them, how long they may take and what gates them, arranged by your operations team without a release.
- 04 The data
- Row-level isolation per tenant and per company, enforced beneath the application. Exports on demand, in formats your systems read.
- 05 The integrations
- Bring your own credentials for credit bureaux, screening and e-signature, so you keep your existing contracts and rates.
- 06 The client relationship
- We are infrastructure. We do not hold the relationship, price the deal, or appear in front of your clients.
Questions
What institutions ask.
Is our data separated from other tenants?
Yes, and not by a filter in the application. Isolation is enforced at the database row level per tenant and per company, so a query that fails to scope itself returns nothing rather than someone else's book.
Can we use our own credit bureau and screening contracts?
Yes. Any integration can run on your own credentials per tenant, which means you keep the contract, the rate and the relationship. The platform default exists so you are not blocked while procurement runs.
Who is the lender?
You are, or your capital partner is. TerraTrade provides the platform and, where you want it, the operational team. We are not the balance sheet unless a separate arrangement says so.
What does the integration work actually involve?
Usually an approved-invoice or client-data feed in each direction, plus single sign-on. REST and webhooks; file exchange where a core system needs it. The scoping conversation gives you a concrete list, not an estimate.
Can we change the onboarding process after launch?
That is the point of it being configuration. Your operations team rearranges stages, owners, deadlines and gates. Deals already running keep the version of the process they started on, so nothing in flight is disturbed.
What happens to our data if we leave?
You get a full export of records, documents and the audit trail in machine-readable form. This is written into the agreement rather than left as a goodwill matter.
Which regulatory approvals do we need?
Whatever your activity and jurisdiction require. That is your perimeter, not ours. TerraTrade provides technology and operational services; regulated activity sits with you or your licensed partners. We will support your submissions with architecture and control documentation.
Next
Scope it against your own programme.
Bring the products you want to offer and the segments you want to serve. We will map what is configuration, what is integration, and what genuinely has to be built.
- An honest split of configuration versus development
- What is not built yet, said plainly
- A timeline with the pilot in it, not just go-live