Client Management

The client management service group allows an Introducing Broker to upload complete details of a prospective client along with all necessary documents. The information is processed by Saxo Bank, and under normal circumstances, a client will subsequently be created. As part of the process the client and the introducing broker may also receive an email with the details of the newly opened account.The exact flow and contents of the email are subject to individual configuration.

Signups Overview

All functionality related to lead signup is collected under the /signups resource.

Currently the following endpoints are available:

Endpoints under cm/v1:

Endpoints under cm/v2:

Typical Usage

Getting Started

Prior to starting the implementation the Introducing Broker and a Saxo Bank account manager must agree what information and what documents the introducing broker must deliver for Saxo Bank to be able to accept the lead as a client. While the /signups resource supports many different client information fields, not all of these are required in all jurisdictions. On the other hand, even if a field is not marked as "required" in the OpenAPI reference documentation, you may have to deliver it anyway.

You will also agree to a small set of different account configurations, that you can specify when submitting the lead signup (see below).

Submitting signup information

The first thing your on boarding service should do is to call the /signups/v2/options resource to get the possible options for fields which require the choice between a set number of options (such as CountryOfResidence or SecondarySourcesOfIncome etc.).

The service should now be able to call POST/signups to submit the required textual information, based on information already collected about the client. Currently you must supply all information in a single call!. The required information is structured as follows:

The PersonalInformation, ProfileInformation and RegulatoriyInformation sections all include information about the client. The AccountInformation section holds information about how the account should be configured, once created.

The possible values for AdditionalChoiceOfAccounts, ClientCategoryId, IntendedCommissionGroupId and IntendedTemplateId must have been agreed with your Saxo account manager, as explained above.

Initial validation and return information

The POST to /signups is subject to limited initial validation. We check for obvious errors, such as required fields missing, incorrectly formatted dates, invalid option values etc. Such validation errors are returned in the form of a standard model error object.

In addition we check if the lead or client already exists in our system, in which case we will return a ClientMatch or a PreClientMatch error.

A successful signup will return:

Adding Documents

You may now be able to add documents to a signup using the /signups/v2/attachments endpoint. You may upload multiple documents of different types, again as discussed with your Saxo account manager.

Marking application complete

By default our system waits about 15 minutes from having received a call to /signup (which creates the core signup record) until it assumes that all information has been received, including all required document attachments. You may however (optionally) call cm/v1/signups/completeapplication to inform our system that all information has been uploaded and we can proceed with application processing.

Monitoring Status 

If the POST to /signups has been accepted you will have received a ClientId, ClientKey and SignupId. This means that the information has been successfully delivered to Saxo Banks onboarding pipeline. From there it may go through several stages. A simplified view of this is provided below:

Initially the application simply "waiting", meaning that Saxo Bank has not yet started processing the application.The next steps is "In progress". During this stage Saxo Bank performs several due diligence and KYC operations. Depending on our operational setup and the legal requirements in the local jurisdiction, an application may remain in the "in progress" state for a few minutes up to several days. From there the application status may switch to:

• Rejected: We will not be able to accept this client under any circumstances.
• Approved: The application is approved, and the creation of the client and account records in our trading and back office system is initiated.
• Pending. We cannot accept the application for a specific reason. If an application is in this state, the introducting broker should take some action to correct the problem. (see below)

Finally, as stated, the client may be in the "Client onboarded" state. At this point the client will be able to log into a trading platform, and it is possible for the client to fund the account and start trading.

The IB onboarding service is able to query the status of any application by calling the GET /signups/status, providing the ClientKey as an identifier.

The response will be as follows:

The OnboardingState will be one of the state names described above

If the OnboardingState is "Pending" the PendingReasons will often include a list of why the application could not be approved.

And example of this is shown below:

Note, this is a pretty comprehensive list of errors, normally there will be fewer:-)

Note also:

• We are not providing defined enums for the "PendingField" and the "Reasons". This is to maintain maximum flexibility in the options of what we test for. At this point we are only providing English text. The intention is to supply the IB valuable information, which a human can act upon.
• In most cases, when an application is in the "Pending" state we will also supply some reasons. There are however a few situations where we will not provide such reasons. In these cases you must contact Saxo Bank to learn the reason for not accepting the application.

Finally, if the application is in OnboardingState "Waiting" or "InProgress" an OnboardingSubStatus field may appear. If this field is included it will have the value "ManualHandling" and this indicates that the application is being processed manually. The calling application can use this information to determine if it should let the user wait online for the result of the application or return later (or await an email).

Integration to external verification provider

Under some circumstances we are able to provide integration with a 3rd party provider of client authentication. Your Saxo Bank account manager will let you know if this is the case and what legal contracts may be required for us to offer this service.

If this is possible, the flow is as follows:

• You will first:
  • call signups/options and /signups to create the initial cilent core record
  • call signups/attachments to upload relevant documentation
• Then you will call /signups/verification/initiate/{clientkey} to start the verification process:
  •  The call must include the url of a call back on your site (the RedirectUrl), which will be called once authentication has been completed by the third party vendor
  • The call will return an IdentificationUrl.
• You must now redirect the browser to this IdentificationUrl.
• The IdentificationUrl is run by the 3rd party identity provider and it will take the client through various steps.
• Once the authentication process has completed, the browser will be redirected back to the RedirectUrl specified in the earlier call.
• From here call the cm/v1/signups/completeapplication to expedite processing of the application.
• Your application may now call the /cm/signups/v1/status endpoint to learn about the status of the application as discussed above.

Requesting Onboarding pdf documents

Under some circumstances IB's can request on boarding pdf documents for their own clients, based on the information they have just submitted. As of now only Switzerland501, Switzerland901 document types are allowed.

You may call this endpoint after you have supplied the necessary information through a previous call to /signups.