Help center › Using Vestoris
User-defined fields
Every reference table has ten user-defined fields (UDFs) the firm can switch on and name: securities, issuers, accounts, account groups, brokers, models, benchmarks, desks, and the entries of restricted, watch and exclusion lists. A UDF holds one value per record. Admins define them; Operations and Admins keep the values. Paper trading only: nothing here is investment advice.
Defining a field (Data › User-defined fields, Admins only)
Pick a table, then a slot (udf_1 to udf_10). For each field:
- Active, a name (unique within the table) and a description shown as help on the forms.
- A type: text (with a maximum length), whole number, decimal (precision and scale), date, yes/no, or a list with ordered options (one per line, "value" or "value=label").
- Required, a default value, and validation: minimum and maximum for numbers and dates, a maximum length, and a pattern for text. Patterns are checked when saved: no groups or back-references, so they always run quickly.
- Where it appears: on forms, searchable (Vestoris adds a database index), on the blotter, in compliance rules, in workflow rules (the last three for securities and accounts).
Describe a field and press Suggest a definition: the AI suggests a name, type, options and validation in the first free slot. Nothing is active until you check it and save. With the AI off a built-in suggestion is used.
Changing a field
- Renaming is always allowed; loads and feeds that use the old name need their mapping updated (the loading center remembers names you map).
- A type change is accepted only if every stored value converts to the new type; otherwise Vestoris lists the records that do not and changes nothing.
- Deactivating hides the field everywhere and keeps its values; activate it again and they are back.
- Clearing values is a separate step that asks you to type
CLEAR <name>and is written to the event log with the number of values removed. - Every definition change gets a new version in the event log with the full definition and the previous one; the History list on the slot shows them.
Where the values show up
- Forms and reference screens: securities, accounts, models and desks have the fields on their own forms and pages. Data › Reference data values covers the other tables (issuers, brokers, account groups, benchmarks, list entries) and lets you search by a searchable UDF.
- The loading center: templates use the UDF names as column headers; a file can use the name or
udf_N, and the mapping is remembered. Values are validated like a form: an inactive slot (U101), a bad value (U102), an XML name that does not match (U103) or a missing required value on a new record (U104) rejects that row with its code. - XML feeds: version 1.1 of each reference format adds an optional
<udfs>element with<udf slot="1" name="Internal rating">BB</udf>. Version 1.0 files are still accepted. See the Data Feed Reference. - The API:
/api/v1/data/{dataset}loads accept the same columns. - The blotter: security and account UDFs marked "on the blotter" are fields in the view editor, with filters, grouping and exports.
- Compliance rules: the "User-defined field condition" rule type blocks or warns when a security's UDF is (or is not) one of some values, optionally only for accounts whose UDF matches, e.g. "Accounts with Mandate code IG-ONLY may not buy securities whose Internal rating is CCC or D". Plain-English authoring knows the field names.
- Workflow rules: conditions on a security or account UDF (in, not in, equals, greater or less than), also from plain English.
- The copilot sees the UDF values of accounts and holdings you are entitled to, and nothing else.
The demo has an Internal rating (a list AAA to D) on securities and a Mandate code (text) on accounts, a compliance rule using both and a workflow rule that raises the priority of orders in securities rated BB or below.