Open Banking in the mortgage support team: who invites, retrieves and reviews?

Separate Open Banking into four jobs before delegating it: initiating the product's invitation and declaration, observing the permitted status, preparing data that has been validly shared, and reviewing it for the mortgage application. A support worker's access to the CRM does not, by itself, settle who may perform each step.

The example here uses the published Frollo from my CRM Broker User Guide, checked on 16 October 2026. Its FAQ says invitations must come from the mortgage broker as Trusted Adviser, including the broker declaration. After the client shares data, the broker may authorise staff to use it for the intended purpose. Those are instructions for that documented product workflow, not universal permissions for every Open Banking service.

Know which relationship the workflow uses

The OAIC lists mortgage brokers among the trusted-adviser professions. An accredited data recipient or CDR representative needs the consumer's relevant consent before disclosing CDR data to the nominated adviser. Trusted-adviser status does not itself make the adviser a CDR participant; applicable privacy and professional obligations still need consideration.

Do not label everyone in the support chain a Trusted Adviser. Identify the nominated adviser, product provider, employing entity and proposed users. If an outsourced worker's place in that arrangement is unclear, obtain the responsible broker's, provider's and privacy owner's clarification before granting access or assigning the task.

This guide proposes an operating sheet for the team. It does not determine your brokerage's legal status, interpret an individual consent or recommend a lending outcome.

Build a four-stage responsibility sheet for the actual product

Start with the current provider instructions for the product and CRM configuration you use. Record the URL, date checked and named owner who will confirm changes. Then add the following proposed role boundaries to your own sheet.

Stage	Named owner and permitted support output	Stop condition
Invitation and declaration	For the documented Frollo CRM workflow, the broker owns this step. Support can prepare an internal request identifying the file and unresolved administrative details.	The task would require the assistant to make the broker declaration or send the invitation as the broker.
Status visibility	The broker and system administrator define whether the support role may view status. An authorised worker records the displayed state, observation time and next owner.	Status is unclear, access is unavailable or the next action exceeds the assigned permission.
Received-data preparation	The responsible owner specifies permitted users, purpose and factual preparation. The worker returns a source-linked inventory or query list within that scope.	Data has not been shared, authority is unclear or the requested use differs from the approved task.
Application review	The broker or other appropriately authorised reviewer accepts the preparation, resolves interpretation and directs the application work.	The support worker is being asked to choose an unsupported interpretation or proceed without the required review.

This table is a suggested division of work. It does not say every product exposes a status-only permission, or that every provider-employed worker is automatically authorised staff. Where the system cannot separate actions adequately, ask the access owner for an approved arrangement rather than sharing the broker's credentials.

Link the agreed sheet to the support access-permissions matrix. Keep consumer consent and authentication with the consumer's own product flow. An assistant should not complete that flow for the consumer or request banking credentials as a workaround.

Teach three exception cards, not one generic reminder

The Frollo guide distinguishes an expired invitation, withdrawn consent and out-of-date data. The following fictional cards show why those states should produce different internal handoffs. They are training exercises, not screenshots or descriptions of real borrower files.

Card One: the invitation has expired

In mock file OB-01, an authorised assistant observes an expired-invitation status. The broker is expecting a preparation update that afternoon. The assistant records the status and time, identifies the preparation task affected and asks the broker to decide the next permitted invitation step.

The assistant does not mark the client uncooperative or resend through a broker-only step. Any customer communication follows the approved wording and owner instruction. The useful handoff is: “Collection not completed; displayed invite status recorded; broker action requested; preparation remains waiting.” It distinguishes a technical state from a judgement about the person.

Card Two: consent has been withdrawn

In mock file OB-02, the team sees a withdrawal state while an older preparation record already exists. The worker pauses further collection activity within their task and routes the question to the responsible broker and privacy owner. They identify the existing record location without copying its contents into a group chat.

Do not infer from this card that all existing records must be deleted, or that every previous use can continue. The responsible owner needs to determine the applicable handling, retention and next-step instructions for the actual arrangement. The assistant records that decision when received; the workflow should not leave them to interpret consent law.

Card Three: the data is stale

In mock file OB-03, data is present, but the displayed state indicates it is out of date. The assistant's output records the source timestamp and the application task awaiting review. The reviewer decides whether and how current information is needed through the authorised product process.

The worker does not replace the timestamp with today's date or treat the existence of data as evidence that it is suitable for submission. A refreshed dataset, if obtained through the approved process, needs a clearly identified version so the broker can distinguish the reviewed pack from an earlier one.

Make the handoff useful without reproducing the data

Use a compact status record: internal file reference; actual displayed state; observation time; applicable provider instruction; task affected; permitted action already taken; next owner; and expected response point. Keep detailed data in the approved system and link to it only for authorised recipients.

After authorised data is available, the bank-statement query handoff helps structure factual coverage questions. Do not repackage every transaction into a new spreadsheet just to demonstrate progress. Specify the smallest preparation output the reviewer actually needs, together with the source and limitations.

If the owner is absent, route the exception to the named backup. A notification alone is not acceptance: the queue should show who has taken responsibility and when the support worker should check again. Preserve a customer's stated deadline as context without promising a completion or approval date.

Test the role before using live files

Give a trainee all three fictional cards and ask them to identify the product instruction, their permitted action, the stop point and the next owner. Then change the scenario: the assistant can see the broker-only button, or an older dataset is still visible after a status change. Check that screen availability does not become assumed authority.

Record the observed result and update the sheet when product instructions, permissions or the engagement arrangement changes. Include those boundaries when defining a loan processor role or sharing a support brief with Mortgage Talent. This is a way to scope the work, not a claim that Mortgage Talent supplies or integrates with the example product.