Vizor API Solution – Submit

Product Description

Vizor Software 2019.Q3

Table of Contents
1 Introduction 3
2 Business Process 3
2.1 High-Level Business Process 3
2.2 Authentication 4
2.3 Service Operations 4
2.3.1 GET /v{version}/returns 4
2.3.2 POST /v{version}/returns/{revisionId}/submit/{returnTypeId}/upload/{clearData} 8
2.3.3 GET /v{version}/returns/{revisionId}/submit/{returnTypeId}/upload/{clearData} 8
2.3.4 GET /v{version}/returns/{revisionId} 9
3 Response Messages 11
4 Security 12
4.1 Transmission Security - SSL 12
4.2 OAuth 2.0 12
4.3 Files Security 15
4.4 Audit Trail 15
4.5 Other Aspects 15
5 Configuration Settings 16
6 Supporting Vizor Builder Configuration 17
6.1 FormSet Properties and Workflow Design 17
6.2 User Roles 18
6.2.1 Machine User 18
6.2.2 Portal Role Permissions 18
7 Limitations 19
8 Glossary 20

Copyright © 2020, Vizor. All rights reserved. Page 2

1 Introduction
The purpose of this document is to describe how machine-to-machine submission of regulatory returns can be
achieved. The mechanism of integration is via OAS 2.0 standard RESTful APIs, allowing authentication, return
data submission and tracking of submission processing status. Essentially, it follows the same process as
successfully uploading a data file, in a structured format e.g. Excel, XML or XBRL, via Vizor Portal.

It is expected that the consumer of this document has the ability to develop a connection to our API endpoints.
Consumers of Section 7 should be familiar with Vizor Builder components.

2 Business Process
2.1 High-Level Business Process

The following describes the process of an API based submission of a regulatory return. While individual
endpoints can be used independently, the subsequent steps describe how API endpoints are best used in an
end to end submission process of a single reporting obligation.

Copyright © 2020, Vizor. All rights reserved. Page 3

2.2 Authentication

The filer’s machine makes a call to establish a connection, using standard Vizor credentials, i.e. username and
password.
For initial set-up, an authorised person at the filer will need to confirm that the “machine user” is associated
with their entity and is authorised. is sent an automatic email containing randomly generated password.
When the human user logs in for the first time, they are forced to change their password which they can then
apply to the machine user.
When successfully authenticated, a token is returned to the filer’s application. The expiry period is
configurable so that several subsequent calls can be made to support the process.
The default token expiry is 30 minutes.
Password expiry and update scenarios are as per human users.

2.3 Service Operations

At a high-level, the following submission operations are included:

Verb URL Description

Returns ready for
completion or partially
GET /v{version}/returns complete but not yet
submitted for all user’s
entities.
File upload to the
POST /v{version}/returns/{revisionId}/submit/{returnTypeId}/upload/{clearData}
requested return
File processing status of
GET /v{version}/returns/{revisionId}/submit/{returnTypeId}/upload/{clearData}
the requested return.
Complete details of the
GET /v{version}/returns/{revisionId}
requested return.

The following are default request parameters which can apply across all operations:

Parameters
Field Name Type Description Examples/ Comments

page Integer Requests the specified page Number of results per response page
where multiple response is configurable (please see
records are possible ‘Configuration’)
version integer The return’s name. ‘1’ is the required value as no other
versions exist at this time

2.3.1 GET /v{version}/returns

This operation retrieves the available returns that are not yet submitted. The scope of the response includes
all returns for all entities the client is permitted to submit on behalf of.
The returns are automatically filtered by:
 user scope – permissions limited based on entities and returns
 return scope and status, i.e. Exposed on Vizor Portal (not ‘Supervisor-Only’), not disabled by
dependency, not ‘Submitted for Approval’ or ‘Accepted’

Details of the request and response parameters are as follows:

Copyright © 2020, Vizor. All rights reserved. Page 5

Request Parameters

No request parameters required as all available returns will be retrieved.

Response Parameters

Parameters

Field Name Type Description Examples/ Comments

id int The return’s unique system ID. The return’s ID.
name string The return’s name.
reference string The return’s reference code.

endDate datetime The return’s end date. YYYY-MM-DDThh:mm:ss.sTZD

status {status} The return’s current status. The status of the last revision.

returnTypes {return-type}[] The return’s type. e.g. “COREP”, “BCAR”, “Solvency II”
entity {entity} The entity with who the
return is associated
revisions {revision}[] The return’s revisions. The revision number of the return

{status}
Name Type Description Examples/ Comments
key int The status’ ID.

name string The status’ name. Terminology depends on client

configuration e.g.
“No Data”, “In Draft”, Valid”

{return-type}

Name Type Description Examples/ Comments

id GUID The return’s type ID. The Return Type GUID.

versionNo int The return’s type version

number.
name string The return’s type name.

{entity}
Name Type Description Examples/ Comments

id int The entity’s ID.

 name string The entity’s name.

reference string The entity’s reference code.

{revision}
Name Type Description Examples/ Comments

id int The revision’s ID. The return’s version ID.

major string The revision’s major version.
minor string The revision’s minor version.
isCurrent boolean The revision’s state of current.

dueDate datetime The revision’s date of due. YYYY-MM-DDThh:mm:ss.sTZD

lastActionPerformed string The revision’s last action
performed.
stateLastChangedOn datetime The revision’s date when state YYYY-MM-DDThh:mm:ss.sTZD
last changed.
hasWarnings boolean The revision’s warnings state. Only “Public” Warnings are returned
to the filer
hasErrors boolean The revision’s errors state.

lastSaved datetime The revision’s date when last YYYY-MM-DDThh:mm:ss.sTZD

saved.
categories {category}[] The revision’s categories.

{category}
Name Type Description Examples/ Comments

id int The category’s ID.

name string The category’s name. e.g. “Periodicity”
options {category- The category’s options.
option}[]

{category-option}
Name Type Description Examples/ Comments

id int The option’s ID.

name string The option’s name. e.g. “Quarterly”, “Annual”

Copyright © 2020, Vizor. All rights reserved. Page 7

2.3.2 POST /v{version}/returns/{revisionId}/submit/{returnTypeId}/upload/{clearData}

This operation allows the client to populate and submit a return containing a single return type. The Vizor API
Service allows the return to be forwarded on for processing – virus scanning, file compatibility check and
business rule execution.

The requirements of the request include:

 The revision ID of the return

 The return’s type ID
 Decision to clear or not clear previous data in that Return
 The data payload of the return type, i.e. the file to populate the Return

Request Parameters

Parameters
Name Type Description Examples/ Comments

{revision-id} integer The return’s revision ID.

{return-type-id} GUID The return’s type ID.

{clear-data} boolean True to clear any previous existing data,

false otherwise.
{file-data} byte[] The data payload of the return type. Multipart content (see web).

Response Parameters

HTTP Response
Name Description Examples/ Comments

200 OK

2.3.3 GET /v{version}/returns/{revisionId}/submit/{returnTypeId}/upload/{clearData}

This operation returns the status of the last uploaded data file for a return of an entity. This will only be
successful if no modification action has been performed to the uploaded data via Vizor Portal from the time of
upload until the time of the request.
If any data modification action has been performed, it produces no result, i.e. HTTP 204 / No Content.
The main purpose of this operation is to determine if the uploaded file has been successfully processed (e.g.
compatible file type uploaded) prior to business rule execution.

The requirements of the request include:

 The revision ID of the return

  The return’s type ID

Request Parameters

Parameters
Name Type Description Examples/ Comments

{revision-id} integer The return’s revision ID.

{return-type-id} GUID The return’s type ID. The Return Type GUID.

Response Parameters

Submission Status Details

Name Type Description Examples/ Comments

revisionId integer The return’s revision ID.

returnTypeId string The return’s type ID. “Solvency II”, “COREP”

fileName string The file’s name.
fileSizeInBytes long The file’s size in bytes.

fileStatus string The file’s status “Processing”, “Processed”

uploadDate datetime The file’s date of upload. “YYYY-MM-DDThh:mm:ss.sTZD”

uploadBy integer The user’s identity who

performed the file upload.

2.3.4 GET /v{version}/returns/{revisionId}

This operation retrieves the details of a specific requested revision of a return. This is primarily used to
retrieve the submission and validation status of a uploaded file in this process.

The requirements of the request include:

 The revision ID of the return

Request Parameters

Parameters
Name Type Description Format / Comments

{revision-id} integer The return’s revision ID. The return’s version ID.

Copyright © 2020, Vizor. All rights reserved. Page 9

Response Parameters

As per the GET /v{version}/returns response parameters, however the return type node is replaced by an
object with different content in this API.

{return-type}
Name Type Description Format / Comments
id GUID The return’s type ID. The Return Type GUID.

versionNo integer The return’s type version

number.
Name string The return’s type name.
endDate datetime The return’s end date. YYYY-MM-DDThh:mm:ss.sTZD
Status {status} The return’s type status. Terminology depends on client
configuration e.g.
“No Data”, “In Draft”, “Valid”,
“Submitted for Approval”,
“Accepted”

returnTypes {return- The return’s types. e.g. “COREP”, “BCAR”, “Solvency II”
type}[]
transformType string The return’s type transform E.g.: “Excel”, “XML”
type.
submissionMode string The return’s type submission I.e.: “Online”, “Offline”
mode.
supportedExtensions string[] The return’s set of supported “.xls”, “.xlsx”, “.xml”
extensions.

Copyright © 2020, Vizor. All rights reserved. Page 10

3 Response Messages
The following response messages will be returned if the requested operation is unsuccessful.

HTTP Status Code Reason Description Remedial Action

204 NoContent The response has no You may have no available
content return obligations
400 BadRequest The request is malformed, Ensure the syntax used in
or syntax used is incorrect the request complies with
the request parameters
401 Unauthorized The request could not be Check machine credentials
authenticated are correct by manually
logging into Vizor Portal
403 Forbidden The request was Check requested operation
authenticated but can be achieved by
execution of the operation manually logging into Vizor
is not permitted Portal
415 UnsupportedMediaType The payload format is Check that the file type is
incorrect correct for the specified
return type
500 InternalServerError A generic response Contact the system
indicating the administrator
4 Security
Security is considered a foundational pillar to ensure the success, stability and value of the Vizor API Solution.
It is paramount to address the security concern properly and actively. The security aspects is a constant theme
of concern and attention while developing the platform and its domains. See “assume breach” paradigm.

4.1 Transmission Security - SSL

Vizor enforces the usage of transmission security (SSL/TLS) for non-development scenarios. The detection of
development and non-development scenario is done at runtime using artefacts detection.

Integrity

Integrity is the ability to maintain the consistency, accuracy and trustworthiness of data. It is ensured using
SSL.

Confidentiality

Confidentiality is the ability to not disclose sensitive information to unwanted recipients. It is ensured using
SSL.

4.2 OAuth 2.0

OAuth (Open Authorization) is an open standard for token-based authentication and authorization on the
Internet.

Vizor APIs are OAuth 2.0 compliant.

Overview

As a general concept, the OAuth standard distinguishes between two main actors:
 the authentication server(s), responsible for:
o client authentication
o authentication token production
 the resource server(s), responsible for:
o client authorization based on authentication token
o resource serving

The process is depicted diagram below:

Authentication (Identity)

Authentication is process of proving the identity of an actor based on a set of credentials (e.g. username &
password, digital certificates, dongles, etc).

The authentication process is based on the user store currently existing in the Vizor ecosystem. Generally, the
set of credentials used to authenticate a user is their username and password. Credentials are matched
against the user store, if proven valid, the user is considered authenticated.

There are currently two types of users inside the Vizor’s ecosystem:
 Vizor Portal users
 Vizor Supervision Centre users

The credentials do not specify against which type of user the authentication should take place; thus the
following strategy is used: user retrieval by username first takes place against Vizor Portal user base, if no
username found, a second lookup takes place against Vizor Supervision Centre users. If no user has been
found in either users stores, the authentication process is terminated. If a user has been found, the
authentication process continues with its remaining flow.

VAS is allowed to act as an authorisation server not physically separated but logically separated, namely
multiple independent instances on a physical machine, each instance with independent purposes (e.g.
authorization only, resources only).

Two-Factor Authentication

The Vizor API Solution does not offer a capability for 2-Factor Authentication, as no industry standard has
been recommended.

Any additional enhancement or configuration effort to implement a client’s preference for additional
authentication can be estimated by the Vizor Professional Services team after detailed requirements
gathering.

Copyright © 2020, Vizor. All rights reserved. Page 13

Authorization

Each VAS domain decides its security requirements. Authorization of an action execution is based on the
authentication token produced by the authentication process.

The authorization data is an authentication token previously generated by the authentication server. It is
transported as a “Bearer” token by the HTTP “Authorize” header of a HTTP request.

By default, all existing requests are required to carry authentication token information.

Tokenisation

The approach to authorize access to a resource utilises an authentication token. The token contains all related
information and access permission of a client.

Since the token is not just a random piece of information uniquely identifying a user, containing intrinsic
information about the user, the token is a Json Web Token (JWT).

The token is re-usable with subsequent calls and has a configurable expiry.

JWT

JSON Web Token is a security token which acts as a container for claims about a user. It can be transmitted
easily between the Authorization server (Token Issuer), and the Resource server (Audience). The claims in JWT
are encoded using JSON.

JSON Web Tokens can be signed following the JSON Web Signature (JWS) specifications, and it can be
encrypted following the JSON Web Encryption (JWE) specifications.

Format

The JWT is a string which consists of three parts separated by a dot (.) The JWT parts are:
 header
 payload
 signature

Example:
<header>.<payload>.<signature>.

JWT Header

The header part is a JSON object always containing 2 nodes. It appears as the following:

{ "typ": "JWT", "alg": "HS256" }

The “type” node has always “JWT” value. The “alg” node contains the algorithm used to sign the token,
namely “HMAC-SHA256”.

JWT Payload

The payload part is a JSON object containing all the claims of a client.

Copyright © 2020, Vizor. All rights reserved. Page 14

JWT Signature

The “signature” node of the JWT is created by taking the header and payload parts, encoded as base 64 and
concatenated by “.”. The “alg” defined in the <header> part is used to generate the signature. The result of
the signing process is byte array which is base 64 encoded and concatenated with the <header>.<payload> to
produce a complete JWT.

4.3 File Security

Virus scanning and the usual file checks are applied to files being processed by Vizor APIs, just like in Vizor
Portal.

Whitelisting
Whitelisting is not managed via the Vizor API Solution. If required, clients can manage IP whitelisting via IIS
configuration.

4.4 Audit Trail

For audit purposes the system logs the events listed in the following table.

Event Source Priority Message and format

Upload started. VATDB Low Upload started. Filename: {file-name}.
Return {revision-id}, formset {return-type-id}, entity {entity-id},
user {user-id}.
Upload completed. VATDB Low Upload completed. Filename: {file-name}.
Return { revision -id}, formset {return-type-id}, entity {entity-id},
user {user-id}.
Upload failed. VATDB High Upload failed. Filename: {file-name}.
Return { revision -id}, formset {return-type-id}, entity {entity-id},
user {user-id}.
Reason: {reason}.
Upload infected. VATDB High Upload infected. Filename: {file-name}.
Return { revision -id}, formset {return-type-id}, entity {entity-id},
user {user-id}.
Reason: {reason}.

4.5 Other Aspects

This section presents other areas related to API security.

Replay Attacks

Replay attacks are automatically addressed by the HTTP protocol.

See: https://stackoverflow.com/questions/36952325/preventing-replay-rest-urls-replay-attack

CORS

Cross-Origin Resource Sharing is disabled by default. At this time, no capability to configure this capability on
is surfaced.

Copyright © 2020, Vizor. All rights reserved. Page 15

5 Configuration Settings

File Changed Key Description

VAS -> Config\Api.Config <add key="System.Api.Results.PageSize" value="15"/> Determines the maximum number of
results that appear in a response page.

VAS -> Config\Api.Config <add key="System.Auth.AccessTokenExpiryInMinues" Determines the expiry of the requested
value="30" /> authentication token.

VAS -> Config\Api.Config <add key="System.Auth.RegEx.Username" value="" /> Determines whether a username
requires a specific format (this
configuration setting is also available in
Vizor Portal/Vizor Supervision Centre).

VAS -> Config\Api.Config <add key="System.Auth.Jwt.X509Key.StoreLocation" Determines the isolation level of the
value="LocalMachine" /> certificates used to generate the
authentication tokens (either machine
wide or user wide).

VAS -> Config\Api.Config <add key="System.Auth.Jwt.X509Key.StoreName" Determines the names of the

value="My" /> compartments within the store.

VAS -> Config\Api.Config <add Determines the key to search the

key="System.Auth.Jwt.X509Key.SearchMethod" certificate by.
value="SerialNumber" />

VAS -> Config\Api.Config <add key="System.Auth.Jwt.X509Key.SearchValue" Determines the value of the key to
value="6f0000000a45ccb2ed59aa6a2300000000000a" search the certificate by.
/>

VAS -> Config\Api.Config <add key="System.Policies.IssuedBefore" Determines that any authentication

value="2019-05-01T14:19:03.712Z" /> token issued previous to the set date is
invalid.
6 Supporting Vizor Builder Configuration
6.1 FormSet Properties and Workflow Design

For a return to be subject to API submission, they must be configured as a return requiring offline processing.

 The FormSet Custom Attribute Offline file upload should be set to True.

 Only FormSets with Supervisor Only – exclude from submission validation on Vizor Portal set as True
should be mapped to the main FormSet.

 The underlying Schema should be included in an Offline File Upload triggered workflow. An example
configuration follows:

Example of a standard offline processing workflow

6.2 User Roles

Two types of users exist in Vizor Software:

 Entity Users are authorised users of reporting entities who login to Vizor Portal. Entity Users may be
assigned access to one or more reporting entities/groups and each reporting entity may have one or
more Entity Users. Only Entity Users need to be considered when setting up a Machine User.

 Internal Users are authorised users within the supervisory authority who log in to Vizor Supervision
Centre. Internal Users may have access to all reporting entities or access can be restricted to specific
entities or groups of entities. This user type is not relevant to the Vizor API Solution.

Vizor APIs – Submit requires an additional Entity User role per sector, which controls authentication to
retrieve the token, and authorises all actions described.

CONFIGURATION OPTIONS
There are no configuration options with user roles for Vizor Portal. Each reporting entity will receive the
following Vizor Portal user per department as part of Vizor Regulatory Returns.

6.2.1 Machine User

A machine user is a role assigned to enable authentication of the machine carrying out the submission process

The following Vizor Portal Role permissions are applied to allow support of the business process.

6.2.2 Portal Role Permissions

Functionality Machine User

View Return Yes
Edit Return No
Clear/Delete Data Yes
Upload Data Yes
Submit Return/Submission History Yes
View Documents & Guidance Notes No
Edit My User Details No
Manage Users No
Create Return No
Delete Return No

Once created, the entity user is sent an automatic email containing randomly generated password. When the
human user logs in for the first time, they are forced to change their password which they can then apply to
the machine user.
7 Limitations
Please consider the following limitations at this time:

 API Submission is supported for returns containing a single return type only
 Note: This limitation does not apply to mapped Supervisor-Only sections
 The IIS file size limit is 2 GB
 Unstructured data is not supported
 Offline processing is the only return processing type supported currently
8 Glossary
Term Definition
API Connector Task A workflow task that supports API-based integration
initiated by the Vizor Platform. Both ‘Push’ and ‘Pull’
Application Log A SQL Server database that retains a complete audit log
of all events that take place in Vizor Portal, Vizor
Supervision Centre and the Vizor API service.
Competent Authority A body responsible for the supervision of entities or
collection of data from entities e.g. Central Bank,
Financial Supervisor, Tax Authority etc.
Competent Authority User A user with access to login to Vizor Supervision Centre.
Compliance Officer/Corporate Service A User who has been granted permission to file data on
Provider/Authorised Third Party behalf of one or more Reporting Entities. They need
only provide their credentials once to begin working
across multiple Reporting Entities in Vizor Portal.
Configuration A change which can be made to metadata or system
configuration settings which can be made by a trained
business user.
Custom Tags (Categories) Additional, configurable attributes which can be
associated with a Return enabling more granular
organisation of submissions. A tag can persist
throughout a Return's life-cycle (e.g. 'audited data' or
'unaudited data') or transition based on workflow
processes (e.g. 'awaiting distribution' or 'distributed')
Data Entry Field A single cell on a Form which can capture either
structured or unstructured data. Multiple custom data
types can be defined to enforce data entry field level
validation – numeric, text, dates, drop-downs, check-
boxes, radio-buttons, attachments, etc. Mapped to a
Schema Item.
Data Model All metadata defined in Vizor Builder.
Data Type Data Types describe the type of data to be collected by
data entry fields and any restrictions to be applied to
the data.
Due Date The submission deadline for a Return, if applicable.
Affects the behaviour of submission deadline
notifications and late return penalty calculations.
Entity Profile A Form associated with each Reporting Entity describing
organizational structure, trading names, related parties,
licenses, etc. for a Reporting Entity as defined by the
Entity Profile component in Vizor Builder
Entity Profile Component A solution component that allows a single FormSet to be
defined to store Entity Profile information e.g.
organization structure, trading names, contacts etc.
Form A single data entry screen which contains both data
entry fields and displays text/graphics. Also referred to
as a Screen.
 FormSet Mapped to a Schema, this design time object contains a
set of child Forms, Folders, and Repeatable Folders. This
represents the visual representation (template) of a
Return.
FormSet Component A Solution Component used to manage FormSets
Group A child element of a Vizor Schema used to structure the
collection of data. A Group represents a logical
collection of other elements, such as the Items collected
by a single Form.
Initial Value A data entry field which is automatically populated by
the system when a Return is created. The value may be
overwritten.
Item A child element of a Vizor Schema used to collect a
single data value. Corresponds to a data entry field
rendered in a Form.
List A child element of a Vizor Schema used to represent
complex dimensional structures. A List is a collection of
other elements. Multiple data values will be collected
for each Item in a List.
Management Information (Ad Hoc Query) Reports A tabular report which displays data from the Vizor
Operational Database. Results can be grouped, sorted
and filtered and exported to various formats.
Metadata The data model configured in Vizor Builder which is
stored in an XML file format and includes data types,
schemas, rules, forms, entity profile, reports, user roles
and workflows
Principal User A Reporting Entity User who has permissions to create
and manage other Reporting Entity Users.
Probability Risk Rating A numeric rating (1-4) which indicates the probability a
risk will crystallise.
Regulatory Return A type of Return, typically used to collect quantitative
data, submitted by Reporting Entities on a periodic
basis.
Release A collection of changes to Metadata representing a
single version of the Competent Authority’s data model.
These changes are packaged together so that they can
be easily deployed to test and production environments.
Repeat Options Form A Form within Repeatable Form(s) which captures a
dimensional attribute(s) that uniquely identifies a
record of Repeatable Form(s).
Repeatable Folder A folder inside a FormSet that allows multiple instances
of its contents to be added in runtime. This type of
folder is used to collect Dimensional Data.
Repeatable Form(s) A Form or group of Forms which are used to collect
multiple records of information (open z-axis
dimensional data) as the number of records will vary per
Reporting Entity (e.g. data per branch, data per director,
etc.)
Reporting Entity / Entity Institutions, companies, firms etc. required to report to
the Competent Authority.
Reporting Entity User / Entity User A user with access to log in to Vizor Portal on behalf of
one or more Reporting Entities.

Copyright © 2020, Vizor. All rights reserved. Page 21

 Reporting Period A period of time measured as a range of days during
which the Return is being reported for.
Resubmission Request An action taken by a Reporting Entity User which makes
a previously submitted Return available for
resubmission, where granted by the Competent
Authority. This results in a revision change (e.g. 1.0 –
1.1).
Return A return is a unique dataset filed by an Entity which can
one or more return types.
A Return can be created on either Vizor Portal or Vizor
Supervision Centre, completed and submitted on Vizor
Portal, and approved and used for reporting on Vizor
Supervision Centre.
Typically, multiple return types included in a single
return is required when data reconciliation checks are
required between dependent return types.
Return Type A Return Type refers to a logical data set that is
submitted by a Reporting Entity and is typically
comprised of many Forms.
The design-time corollary is a FormSet, which is mapped
to a schema.
Return Schedule A Return Schedule specifies a timetable for the
automated allocation of Returns to the correct Entities
at the expected frequency.
Roles Component A Solution Component used to manage User Roles
Runtime A term referring to when a Release has been deployed
and is in use in Vizor Portal and Vizor Supervision
Centre, as opposed to design-time where the solution is
being designed in the Vizor Builder
Schema A Metadata element managed by the Vizor Builder that
defines a hierarchical structure for data which will be
collected within a Return.
Schema Component A Solution Component used to manage Schemas
Schema Element A child element of a Vizor Schema used to structure the
collection of data. A Schema Element can be a List,
Group, or Item
Schema Folder An optional element which can be used to create a
logical grouping of Schemas for ease of management,
for example by industry or business area
Schema Instance A single uniquely-identifiable instance of a Vizor
Schema. Schema instances are used to hold collected
data in a structured manner.
Send Back (Reject) An action taken by a Competent Authority user which
makes a previously submitted Return available for
resubmission.
This results in a revision change (e.g. 1.0 – 1.1).
Solution Component A software component used by Vizor Builder to design
and manage metadata for a certain part of a Vizor
Solution. Components exist for Roles, FormSets,
Schemas, Workflow, and Entity Profiles.
Submission A process by which a Return validated through Vizor
Portal is made available for review on Vizor Supervision

Copyright © 2020, Vizor. All rights reserved. Page 22

 Centre.
This results in a revision change (e.g. 0.1 – 1.0).
Supervisor-Only An attribute that can be applied to a FormSet to hide
the FormSet from Reporting Entity users and show it
only to Competent Authority users (Assessment Forms).
Tracking Status The current status of a Return in the submission
process.
User Role Gives a user access to a combination of features and
Returns. User Role(s) are then combined with Entity(s)
and Entity Group(s) to fine tune a user’s permission set.
Validation Error Where a Validation Rule executes resulting in a ‘hard-
fail’ condition. Users cannot continue with submission if
a validation error occurs.
Validation Rule A validation check that runs a conditional expression
against one or more Schemas and passes or fails based
on the Boolean result of the expression.
Validation Warning Where a Validation Rule executes resulting in a ‘soft-fail’
condition. Users can continue with submission if a
validation warning occurs. Validation Warnings can be
hidden from a Reporting Entities view (e.g. to support
plausibility assessment)
Vizor Analytics A product add-on in which the Vizor Data Warehouse is
leveraged with a third party BI tool such as MS PowerBI
to enable self-service report definition.
Vizor API Service A collection of APIs which support machine-to-machine
regulatory processes. Each process is licensed separately
as a module and may leverage several individual APIs to
support that business process.
Vizor API Service - Submit A collection of APIs that support the submission process
– retrieve current reporting obligations, upload a file
and return the outcome.
Vizor Builder A Microsoft Windows desktop application which is used
for the design and definition of Metadata.
Vizor Cybersecurity Provides advanced security features for Vizor Software
and pro-active monitoring in an add-on module and
services package.
Vizor Data Warehouse A SQL Server database which stores instance data
dimensionally, thus optimised for BI reporting.
Refreshed on a nightly basis.
Vizor Licensing and Regulatory Transactions Enables Reporting Entities to submit license requests
and authorisation applications online. Once approved,
any affected Entity Profile data is automatically
updated.
Vizor Operational Database An SQL Server database which stores instance data in
real-time.
Vizor Portal An ASP.Net web application used to submit and view
data on behalf of Reporting Entities.
Vizor Regulatory Returns Allows Regulatory Returns to be scheduled, collected,
validated, assessed, analysed, distributed and shared
Vizor Risk-Based Supervision Allows the Competent Authority to record the results of
both off-site and on-site supervision activities and
combine this with automatically calculated Key Risk
Indicators

Copyright © 2020, Vizor. All rights reserved. Page 23

 Vizor Supervision Centre An ASP.Net web application used by Competent
Authority Users to create and manage System Settings,
Returns, Users, Entities, MI Reports, etc.
Workflow A workflow defines a set of tasks that are executed
when a particular Vizor Portal or Vizor Supervision
Centre event occurs, typically used for automating
processes associated with Returns. The tasks contained
within a workflow should represent a logical flow of
work to be performed when triggered by a defined
event.
Workflow Component A Solution Component used to manage workflows.

Copyright © 2020, Vizor. All rights reserved. Page 24