Setting up identity verification

Identity verification controls when the assistant is willing to share personal account information with a customer and when it asks that person to prove who they are first. It ships with every workspace and is never billed separately.

This page takes an operator from “no verification configured” to a first verification in three steps.

Before you start: find your customers

Verification asks a customer to prove they are a specific customer of yours, so oHallo has to be able to find that person in your systems first. Set up Settings → Customer records before this page: see Finding your customers. Without it there is no record to draw a question from and nowhere to send a verification link. National eID reads two further designations on the same page: the eID reference on the record and the national identity number.

What you’ll set up

1. National eID, where offered: the customer approves in their own MitID or BankID app, and a completed approval verifies them at high assurance on its own.
2. The email link, a one-time link sent to the address held on the customer’s own record.
3. A question your customer can answer from their own record, such as the postcode an order is going to, or the last four digits of an invoice number. You choose from the suggested questions or write your own, then point it at the MCP tool and the field that holds the answer.
4. A required assurance level on each MCP tool, so a tool that returns personal data waits for a verified customer.

Step 1: Add a question

Open Settings, then Verification, and open the Questions tab. Click Add question. The panel asks you to pick one of the suggested questions or write your own, then choose:

• An MCP connection from your MCP hub. This is the connection you already use to fetch account data when the assistant runs other tools.
• A tool from that connection, and the field in its answer that holds the value the customer has to match.
• Which record to check, meaning where the value the customer is being asked about comes from: what they asked about, the email they wrote from, or the phone they called from.

A tool that declares what it accepts and returns gives you dropdowns for the input and the field. A tool that does not lets you type them exactly, and a path that stops resolving is flagged on the question’s own row.

Every enabled question that applies to a customer has to be answered correctly, so start with one or two and add more as you see them working.

Step 2: Confirm the policy

Below the questions, the Policy section holds four settings. The defaults follow NIST SP 800-63A and PSD2 SCA, so most workspaces leave them alone.

• Wrong answers allowed: the default is 3. A wrong answer re-asks the same question, and going past this ends the verification.
• Failed verifications before lockout and Lockout duration: the default is 5 failures in 24 hours, then a 24-hour lockout.
• Cross-channel carry: off by default. Turning it on lets a verification stand beyond the conversation it was earned in, and the Posture tab records that choice.

Caller ID and Email sender address live per channel, on the Channels tab under Customise. “Supporting” keeps a question in the flow. “Accept on its own” lets the signal identify the customer by itself, and the Posture tab records that choice too. Neither can ever reach high assurance, whatever you set.

The Email link tab holds the mechanism itself: whether it is on, how long a link stays valid, and which channel it is sent from. The destination is always the address on the customer’s own record, set in Settings → Customer records.

The National eID tab lets customers verify in their own eID app. Choose Add country to offer MitID or BankID; each country carries its own broker agreement and client credentials, and its row shows a readiness line saying what runs: the app approval, the verification link, or what is still needed. Denmark’s MitID is the scheme that verifies today; a combination that is still to be proven says so on its row and activates once it has been proven end to end. The method reads the eID reference and the personal number from your customer records, and it is offered on email, voice and live chat channels: turn it on per channel on the Channels tab under Customise. For email channels the tab also holds the delivery choice: the approval goes straight to the customer’s app, or the reply carries a verification link that opens the scheme login. In live chat the verification arrives as a button in the conversation itself. The full method is described in Verifying with a national eID.

Question toggles and channel changes save where you make them. The Policy settings and the Email link tab save with the Save button at the foot of the page.

Step 3: Set per-tool assurance levels

Open MCP hub from the sidebar, then your connection. Each row in the Tools table carries a Risk and an Assurance setting.

Give every tool a risk classification first. A tool left unclassified is declined on every call, rather than treated as open.

• anonymous: no identification required. Available for tools classified read.
• identified: the customer must be linked to a record before the tool runs. The floor for read (PII), write and write (PII).
• high-assurance: a second proof of a different kind is also required. The floor for destructive tools such as cancellations and refunds.

The Assurance list starts at the floor for that tool’s risk classification, so you can raise the requirement and the floor holds underneath it. Hover the control to see the floor.

Check it will work

The Channels tab ends with Will a caller be verified?, one line per channel saying what fires there and what cannot be asked. Read it before you go live. Verification works on voice, email, chat and WhatsApp, and a question that depends on something a channel cannot supply is listed as blocked there rather than failing quietly on a live conversation. Where National eID is turned on for a channel, its row also says whether the customer can approve in their eID app, and points at the National eID tab when something is still needed.

You’re ready

Verification starts the first time the assistant reaches a tool that needs an identified customer. That person answers the enabled questions, and where you have turned the email link on for that channel, a one-time link goes to the address on their own record. Every step lands in Identity events, reachable from the Posture tab.

To stop the assistant asking for verification on a particular tool, set that tool’s assurance to anonymous, which is available once its risk classification is read.