Requesting Information from a Third Party

Many compliance and operational processes require information to be provided directly by a third party — a document to complete a payment, details to onboard a new customer, evidence to back a source-of-wealth check. By the end of this tutorial, you'll have requested information from a third party in BNDRY through a secure, branded portal, and you'll know where their response lands and how it shows up against the customer afterwards.

What requesting information is for

Plenty of work can't be finished from the inside. A payment needs an extra detail before it can be processed. A prospective customer has to supply identification before you can onboard them. An investigation needs documents that only the customer holds. In each case, you need a clean, secure way to ask someone outside your organisation for information — and to keep what comes back.

The usual alternatives are email, phone, and PDFs sent back and forth. None of them produce an audit trail, none of them scale, and none of them give the other party an experience that inspires much confidence. BNDRY's answer is the portal: a secure, branded space where a third party completes the forms you've asked them to, uploads what you need, and submits it straight back into the record you're working from. The same approach covers a wide range of uses — payment requests for information (RFIs), individual and merchant onboarding, source-of-wealth checks, and information-gathering during an investigation — because in every one of them the underlying need is the same: ask securely, and keep what comes back.

Before you start

A few things to have in place:

• You can sign in to BNDRY with a role that lets you create Workspaces and share them. If you're not sure, check with your administrator.
• You have a form that captures what you want to ask for. You can configure forms specifically for external collaboration — see Designing form templates.
• The entity you're collecting information about exists in BNDRY, so the request can be tied to the right record. The Entities explanation covers how entities work.
• For background on the external surface itself, the Portals explanation is a useful read — though you don't need it to follow along.

Phase 1 — Choose the form that asks for what you need

What you ask for is defined by the form, so the request starts there. You can request information against any form, which means you can design forms specifically for external collaboration — an onboarding form, a payment RFI form, a source-of-wealth declaration — each shaped to capture exactly the details that particular request needs.

Pick or build the form that matches your use case. The fields you include, and the file uploads you ask for, are what the third party will see and complete. Designing it well is what makes the request feel deliberate to the recipient rather than like a generic questionnaire.

Phase 2 — Create a Workspace and add the form

The Workspace is the container that holds this request and everything that comes back. Create a Workspace and add the form you chose, then link the entity the request concerns. Give the Workspace a name that identifies what it's for, such as "Onboarding — June 2026".

Linking the entity matters for what happens later. The third party's submission won't overwrite the fields on the entity's profile — that's not how it works — but because the Workspace is linked to the entity, the whole request becomes part of that entity's history. You'll be able to look at the customer later and see that this request happened, what it was, and how it was resolved.

Phase 3 — Share the Workspace through the portal

This is the step that reaches the third party. Sharing a Workspace generates a secure magic link to the portal — a separate, branded web space, carrying your organisation's logo and colours, where the recipient completes the work.

Generate the share for the recipient's email address. Two things are worth setting deliberately:

• Scope — the link can grant access to the whole Workspace or to a chosen subset of its forms. Share only what the recipient needs to see and nothing more.
• Expiry — the link is time-bound, with an expiry you set between one and sixty days. Once it lapses, the access closes.

Send the link. The recipient opens it and lands in the portal scoped to exactly what you shared.

Phase 4 — The third party completes and submits

In the portal, the recipient sees the form rendered in a state they can complete. They fill in the fields, upload any documents you asked for, and submit. Everything they do lands back in the same Workspace your team works from — there's no re-keying, no copying from an email, and no separate inbox to reconcile.

Phase 5 — Review what came back, and where it lives

Open the Workspace and review the submission. The completed form and its responses sit on the Workspace, ready for your team to act on.

It's worth being clear about where the information lives afterwards, because this is what makes the request part of the customer's lasting record:

• The Workspace itself appears in the linked entity's history and activity log, so the request is visible from the customer's record.
• Any documents and files the third party uploaded appear on the entity's Files tab, kept against the customer rather than buried in an email.

Once you've reviewed and acted on the response, set the Workspace status to Resolved. The request is now a closed, auditable part of the customer's history.

What you've learned

You've requested information from a third party end to end: chosen the form that asks for what you need, put it in a Workspace linked to the right customer, shared it through a secure branded portal with a scope and expiry you controlled, and seen where the response lands afterwards. You know that the submission lives on the Workspace, that the Workspace surfaces on the entity's history through the link, and that uploaded files land on the entity's Files tab. The same approach works whether you're processing a payment, onboarding a customer, or gathering evidence for an investigation.

Next steps

• Designing form templates — shape forms specifically for external collaboration so each request asks for exactly what it needs.
• Portals — how the external surface works, including branding and the magic-link access model.
• Conducting Enhanced Customer Due Diligence in BNDRY — a worked example of requesting information from a customer as part of a specific compliance process.