Fundamental principles of LUSID

Before you start a free trial and explore all the applications in the FINBOURNE platform, it's important to understand the core concepts underpinning LUSID.

LUSID has a schema-on-read data model

LUSID's data model is designed to be flexible rather than constrain your data to our view of the world. We require you to model only a small set of real-world objects as entities. For example:

  • An instrument represents a real-world financial asset such as an equity, swap, option, bond, currency and more.

  • A transaction represents economic activity in a particular instrument, such as the purchase or sale of an equity.

  • A portfolio represents a store of transactions and other economic activity affecting one or more instruments.

  • A holding represents your position in a particular instrument, as automatically generated by LUSID from the history of activity in a particular portfolio.

See the full list of LUSID entities and their key characteristics. If you need to extend the built-in set, you can create custom entities (see the extensibility section below).

By design, an entity has a minimal set of fields. For example, to create a portfolio you only need specify values for the name, scope, code, and base currency fields. A portfolio has a few other optional fields as well that either default to sensible values or can be left empty. However, you can extend a portfolio (and most entities) by adding properties to store as much additional information as you need (see the extensibility section below).

LUSID also provides core system settings to make key operations possible out-of-the-box:

  • Transaction types such as Buy and Sell. These define the economic impact of activity, so for example applying the built-in Buy type to an equity transaction automatically increases your position by the number of units bought and decreases your cash balance by the total cost.

  • System properties such as TradeToPortfolioRate and BondInterest. These built-in functions either provide access to useful system information (if read-only), or enable users to enter data that LUSID can then use in calculation or other business operations.

  • Data types such as Rating and AccountingMethod. These constrain and validate property values, so for example the Rating type only allows users to enter values such as AA or BBB into properties representing credit ratings.

  • Cut labels such as LondonOpen or NewYorkClose. These replace timestamps with meaningful names, making it easier to work across multiple time zones.

LUSID’s data model is fully extensible

You can extend almost any aspect of LUSID's data model. This means you can consolidate data from different systems without undertaking expensive and time-consuming ETL operations, by mapping discrepancies between systems onto custom properties or entities. Data stored by LUSID in this way retains its format and lineage, so it remains meaningful to the originating system.

You can:

  • Extend most built-in entities by adding properties. For example, you could create an Executing Broker property to add to transactions, or a Manager property to portfolios. Properties can have single values, multiple values, or values derived from mathematical or other operations, and can be optional or mandatory. More information.

  • Create custom entities to model real-world objects that LUSID does not natively represent. For example, you could create an Organisation entity to represent the concept of business units. More information.

  • Create custom settings such as:

    • Transaction types. For example, you could create a BuyPlusCommission type that extends the built-in Buy type to record commission paid to brokers. See how to do this.

    • Data types. For example, you could create a NaceCode type that constrains properties to valid NACE industry codes, and additionally stores additional reference data such as the economic definition of each code. See how to do this.

    • Cut labels. For example, you could create a SingaporeOpen label to represent the start of trading in the Singapore time zone.

Data from different systems can co-exist in LUSID but you can extract business intelligence as though it were a homogeneous set. For example:

  • Instruments can have multiple market identifiers, so you can load transaction data from different systems (one using FIGIs and another ISINs, for example) and LUSID can resolve them to the same instrument, guaranteeing an accurate position.

  • Transaction types can be grouped and aliased, so a Buy transaction from one system can have the same economic impact as a BY or Acheter from others.

  • Derived properties can reconcile information from different systems by mapping, coalescing or transforming properties to a single point of reference.

  • Recipes can marshal pricing data from different vendors and incorporate a waterfall of pricing models and methodologies to enable numerous streams of information to inform valuation operations.

LUSID has a fine-grained entitlements system

LUSID denies access to all resources for every user—whether human being or automated service, either via the web app or by calling the API directly—until explicitly allowed.

LUSID has separate identity management and access control systems that work together to authenticate users and grant each the permissions they need to access data and perform operations in keeping with their professional responsibilities, and no more. Read our IAM documentation.

LUSID partitions and entitles data using scopes and codes

Almost every data item in LUSID must be assigned to a scope (or namespace). This enables you to:

  • Replicate data in different scopes. For example, you could duplicate a portfolio and evaluate different trading strategies in the two scopes.

  • Store the same kind of data from different systems in separate scopes. For example, you could store equity prices from Refinitiv and Bloomberg in two scopes, and value a portfolio against one and then against the other.

  • Assign access control permissions to scopes. For example, you could assign all US portfolios to a scope that only US-based managers are allowed to manage.

Within a scope, a data item has a code; together, the scope and code uniquely identify that data item. More information.

LUSID is bitemporal and immutable

Almost every data item in LUSID is stored with two timestamps:

  • A read/write effective at timestamp that describes when the data item is valid (that is, meaningful) from a business point of view.

  • A read-only as at timestamp that records when the data item is entered into LUSID.

You can roll back either timeline, which gives you unparalleled audit capability. For example, you could correct a wrongly-entered transaction, which leaves the transaction with the original effective at timestamp but gives it a new as at timestamp. You can then query LUSID for either the data as it is now, or roll back the as at timeline to query for the data as it was before the correction.

The important implication here is that no data is ever truly deleted in LUSID. This is because it must be possible to roll back the as at timeline to recreate the data as it was in the past. So when you 'delete' (for example) an instrument, what you are actually doing is time-limiting it's effective at timestamp from the as at timestamp of the delete operation. More information.

LUSID is an ecosystem of applications

The core LUSID investment management application is a RESTful API that you can integrate or build upon. LUSID also has a web app (GUI front end) that exercises the API and can be used as a standalone application if you wish.

The LUSID ecosystem also includes the following supporting applications:

  • Scheduler: job scheduling and automation

  • Drive: file storage and management

  • Luminesce: data virtualisation and query engine for LUSID and other SQL-compliant applications

  • Configuration Store: central repository for secrets and parameters

See the full list of applications.

LUSID has numerous operational interfaces

You can perform CRUD operations, and also analytical and reporting tasks, on the investment data stored in LUSID using the following tools and interfaces:

  • REST API (API Reference sandbox available). Note other interfaces may be better suited to bulk loading data into LUSID.

  • SDK, available in multiple languages and frameworks: Python, C#, Java, JavaScript and Angular.

  • LUSID Python Tools (LPT), which builds upon the Python SDK to make common operations easier in Python environments.

  • Web app. Note not every API operation is available from the GUI front end.

  • Luminesce. Note a separate license is required to read and write data to/from LUSID using this data virtualisation application.

  • Jupyterhub, which can run code in Jupyter Notebooks to perform operations in your LUSID domain.

  • Excel add-in, which provides a set of Excel functions to interact with the LUSID API.