Open API

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:

Method/EndpointPurpose
POST /signupsDeliver a complete set of client information by posting a JSON structure to Saxo Bank.
GET /signups/options

A number of the fields to be provided to POST /signups must be one of a pre-selected set of values (options).

Call this endpoint to get a list of possible values for these fields.

POST /signups/attachmentsUpload a number of documents related to a particular signup.

GET /signups/status

Gets the status of the signup. How far is Saxo with the processing of the lead?


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/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 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/attachments endpoint. You may upload multiple documents of different types, again as discussed with your Saxo account manager.

Monitoring Status (Expected Delivery 24/2-2018)

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.