The Xama integration in Socket is a helpful addition if you’re using Xama for AML — and this is just the beginning. We’re continuing to build on it with more features coming soon.

With this integration you’ll be able to:

Gain Quick access to Xama: When first setting up the integration, Socket will try to match your existing clients in Xama with those already in your Socket account and automatically link them. Once linked, you can jump straight from a client’s page in Socket to their profile in Xama.

Use Xama clients in proposals: Once linked, your Xama clients will appear when creating proposals in your ‘Existing Clients’ list. This makes it easy to pull in existing client details without extra data entry - as long as you don’t have another CRM integration.

AML tab in Socket: Clients and prospects will have an AML tab on their Client Details page in Socket. From there, you can view their full risk assessment history, manage who needs checking, and click through to their Xama profile.

Identity verification in Forms: Add an Identity verification field to a Socket form and it links to the client’s Xama integration, so their ID check runs through Xama. See the section below for more.

Once your clients have synced, click on 'External links' and then on the Xama client and this will take you directly to the Xama record.

When creating a new proposal, any Xama clients will be listed with 'Xama' next to the record.

On the Xama integration you'll find a Automatically push new clients to Xama toggle. With it on, when a prospect becomes an active client in Socket a matching Xama account is created for them, so you're not keying the same client into two systems.

If Socket spots what looks like a duplicate in Xama, it skips creating anything and tells you instead, so you can go and link the existing record rather than end up with two.

Click into the client's record to see the AML tab displayed. Here we will show the details of any risk assessments, and it's also where you manage who needs checking.

The AML tab is available on prospects as well as active clients, so you can get someone's AML in motion before they've signed anything if that's how your practice works.

Underneath the risk assessments you'll find Key People, the list of individuals connected to that client. Each row shows where they've got to: their status, whether an onboarding request or AML check is outstanding, whether monitoring is on, and whether documents are in.

Three buttons sit above the list:

Adding people here creates their records in Xama but doesn't start anything. Nothing is sent to your client and no check begins until an onboarding request is live and they complete the verification.

You can also create an onboarding request from here at any time, and email the client from here if you'd rather do it that way than through a form. Sync latest risk assessments pulls the current position back from Xama if you've been working over there.

Doing all of that by hand for every client adds up, so you can have Socket do the setting up for you. On the Xama integration, click Onboarding Automation.

The idea is that when a proposal is won and the client is pushed to Xama, Socket creates the onboarding requests at the same time, so the ID checks are already sitting in your onboarding form before the client opens it.

There are three ways to run this, and which suits you depends on how your practice handles AML.

Don't create anything. You add the people and create the requests yourself, in your own time. Pick this if you'd rather keep AML in Xama, or you send your onboarding form later and want to control each step. Worth knowing: with no request in place when the proposal is signed, an Identity verification step on a form attached to that proposal has nothing to show yet. Create the request and the step appears.

For existing contacts only. Socket creates requests when the proposal is won, but only for the people already on the client's record. This is the one for practices who check certain directors rather than all of them. Add the client as a prospect, add just the individuals you want checked, and leave it. When the proposal is won, requests go live for exactly those people and nobody else.

For all company directors and existing contacts. The fullest option, for practices who check every director as a matter of course. When the proposal is won, Socket creates the Xama record if there isn't one, brings through every officer listed at Companies House, and creates the requests. If the client is already in Xama it adds any directors who aren't there yet and leaves the ones that are. Anyone you'd added yourself who isn't a director is included too.

Underneath, choose which onboarding level auto-created requests should use. These come from your own Xama account, so the options you see are the ones your practice has set up over there, and how thorough each level is is a Xama decision rather than a Socket one.

Setting it here means requests Socket creates for you are raised at the level you'd have picked anyway.

You can override the setting on an individual proposal from its Customise step, so a client who needs handling differently doesn't mean changing it for everybody.

Whichever setting you choose, working by hand still works exactly as before. The setting is about what happens without you, not about what you're allowed to do. And if anything can't be created, Socket notifies you rather than failing quietly.

Nothing is sent when a request is created, so if someone comes through who you don't need to check, archive them on the AML tab before your client reaches the form.

Once the integration is connected, you can include identity verification inside a Socket form. Add the Identity verification field when building a form and it links to the client’s Xama integration, so the ID check runs through Xama and the result is read only in Socket. There is more on adding fields in our Building your form guide.

Adding the field to your form is not the only step. The Identity verification step only appears to a client when there is an outstanding onboarding request for them in Socket. If there is no request, the step is hidden and the client can complete and submit the rest of the form as normal. This is deliberate, so your clients are never shown an empty verification step.

How the request gets there depends on your Onboarding Automation setting. Either Socket creates it when the proposal is won, or you create it yourself from the client's AML tab, choosing which people need an ID check.

If you're doing it by hand, the recommended order is:

Forms are live, so if the client already has the form open or received it earlier, creating the onboarding request makes the verification step appear without you needing to resend anything.

💡 Testing tip: the step will not appear when testing with a made-up company, because there is no real onboarding request behind it. To see it working, use a client with an outstanding onboarding request and preview the form link.

If you need to know who the directors and significant shareholders (over 25%) are before you can run your checks, a two-form approach works well:

If your practice checks all directors, Sync People and the all-directors automation option do much of this for you, since the Companies House officers come through on their own.