Being able to offer buying and selling of equities through various apps and FinTech offerings is gaining in popularity and traditional mutual fund brokers is seeing the need for adding single stocks to their universe of investible assets too.

This article builds upon the article called How to get started with Bricknode as a core banking system for current accounts in 30 minutes

Adding the instrument type

The first order of business is to activate the instrument type for stocks, I will navigate to the marketplace and then find the add-on for stocks.

With this add-on enabled I can go on and add stocks to the system, this can be done automatically from a data feed, via API or manually. Bricknode has a feed for reference data (all the basic information about a stock) and end of day pricing data that can be enabled for a system and then all instruments available on subscribed exchanges will be imported into the system and a daily price feed activated.

For demonstration purposes I will add the stock of Apple manually in this article.

There are some pre-requisites that are needed when adding a stock so that things like order routing and TRS reporting can function properly. One of those things are the setting for primary market. Within the “System Data” section there is a selection called Places.

This is the area where I will register the exchanges where the instruments are listed. I will start off by adding Nasdaq US as a market.

Now I can navigate to the instruments section and select Stocks and then simply click the “Create” button to get a new dialogue for creating a new stock instrument.

The first view will look like this.

As can be seen there is a setting called Issuer where I can register the issuer of the stock if I wish, in this case this would be Apple Inc. and if I want to get the full value of the system I can use this granularity but I do not need to work with issuers to simply offer investing in this stock so I will leave it for now.

On the next screen I define some properties for the instrument.

On the last screen I can enter various categorizations like for example risk groups, industry groups etc. Categorizations are highly configurable but outside the scope of this article.

When I click “Create” the instrument will be created and I will be asked if I want to create an Execution Interface.

What in the world is an Execution Interface?

An Execution Interface is a trade route, it defines how orders are going to be executed. If I have activated an integration to a broker or bank I will have that as an available Execution Interface with the relevant settings for that trade route.

In this example I will configure the Manual Execution Interface. Before I do this I will set up a new custody account that will mirror the brokerage account that I am using for safekeeping of the stocks that are bought.

Just as in the previous article the custody account is created from the House View.

Bank 1 will be the Legal Entity that will act as a counterparty to all trades as my broker and thus I need to create a Counterparty Account for this Legal Entity too. I do this by navigating to the Company and then I create the new account of the Counterparty Account Type.

Now I can go back and create the Execution Interface.

Let’s add some data

Finally I will get some historic data for the instrument which I can import via API, files, enter manually or by activating an add-on with end of day data for the instrument, this way I can see a chart and start using historic performance calculations too.

All is now set and as a back-office user I can enter trades on behalf of accounts.

The Financial Advisor with Power Of Attorney for a customer can enter orders too.

And finally the end customer can log on and enter trade orders as well.

Complete order management capabilities are available through our API too for you to build your own customer experiences and automation.

Please get in touch with us to explore your case further!

Many times when we extend the use of Bricknode Financial Systems (BFS) by building applications on top of it using the API we end up with the need for more property fields. BFS has a lot of dedicated fields but when we need more we can use Custom Fields! Every object in BFS has Custom Fields, it is part of the Entity Base class.

Custom Fields store data in simple string format and in the old days we might have worked with for example semicolon separated values. During the last couple of years we have changed this behaviour and began working with JSON data in Custom Fields instead. This way the data in Custom Fields both become more easy to read and edit in the regular GUIs and for developers the data is more structured.

We have a plan to integrate a GUI editor for fields that contain JSON which will make the life easier for non-developers but for now GUI users can work with tools like Excel that can be converted to JSON format with tools like this one for example:

Now onto an example. I am building a new application that will take care of recurring fees based on assets under management in BFS.

I do not want to set up a separate database for this application but instead use BFS for all my data needs. There are a few things that I need to take care of.

I am calling this application RecurringAumFees and thus it is good practice to name the Custom Fields with this prefix.

To communicate with BFS I am using our NuGet package.

Let’s have a look at the class that I call RecurringAumFee_HouseSettings.

/// <summary>
///     This model is used to collect data from the House in the BFS instance from the custom field called
///     RecurringAumFees_HouseSettings
/// </summary>
public class RecurringAumFees_HouseSettings
    /// <summary>
    /// This is the interval of how often the fee should be applied
    /// </summary>
    public FeeInterval FeeInterval { get; set; }
    /// <summary>
    /// This is the date when fees were last executed
    /// </summary>
    public DateTime LastFeeExecutionDate { get; set; }
    /// <summary>
    /// This is the first date that fees should be executed
    /// </summary>
    public DateTime FirstFeeExecutionDate { get; set; }

The FeeInterval property is an enum looking like this:

public enum FeeInterval

As a GUI user I can put this data into an Excel sheet according to the template below.


I can then visit the conversion tool and import the Excel file and then extract the following data.

 "FeeInterval": "1",
 "FirstFeeExecutionDate": "3/31/20"

I navigate to the House View in Bricknode Broker.

On to the details section.

And create a new Custom Field where I paste the JSON formatted data.

The result:

Now in my application I can just collect the house data and deserialize the Custom Field values into a C# object to work with it like this.

public async Task GetRecurringAumFeesHouseSettings()
    var houseData = await _bfsLegalEntitiesService.GetHouseInformationAsync("[yourinstancename]");

    var recurringAumFeesHouseSettings = houseData.Result.First().CustomFields
        .First(t => t.FieldName == "RecurringAumFees_HouseSettings").Value;

    var recurringAumFeesHouseSettingsObject =

The data that I got back looked like this.

In my humble opinion this is the absolute best way to work with complex Custom Fields in BFS and not have to create one Custom Field per value or use generic separators.

How should financial institutions think about their future IT needs to stay competitive and offer superior value and experiences for customers?

In our opinion, the days are numbered for monolithic software systems being custom developed for financial institutions seeking to streamline their current operations. In a rapidly developing world where regulations are continually changing, together with customer needs and distribution channels, the focus should be on selecting the right standardized platform to use as the foundation.

What do we mean by this? Well, we think that a lot of stuff can be standardized but not the customer experience. It will be critical for financial institutions to accept the fact that their IT should be viewed as an opportunity and an asset as opposed to a necessary evil.

A good core platform should offer the basics to take care of things like accounts, transactions, customers and financial instruments. The platform should also have an excellent API which the financial institution could use to let its own developers extend the platform with their own software. Having an API in the core platform also enables the financial institution to allow partners to interact with it and will make them PSD2 compliant from day one.

Another vital area is configurability, you should be able to configure a lot of things so that you don’t have to be dependent on new functionality being implemented from the platform developer when it comes to trivial matters.

Let us continue by describing briefly how we have reasoned on the above points within Bricknode.

Standardization and API

Bricknode Financial Systems (BFS) is a core platform with numerous add-ons or modules that can be activated in our marketplace, or “app store” if you will. The core platform offers a comprehensive API where almost everything can be conducted programmatically in the platform.

Our users are then encouraged to build their own specialized components like customer front ends, mobile apps or whatever it could be that they would like to offer their end customer.


BFS is a very dynamic platform, the user can create their own account types, account type behaviors, transaction types with associated automated transaction chains and much more, directly in the graphical user interface (GUI) or by merely uploading XML-based configuration files straight into the GUI.

The next ten years of financial IT should be focused on modular solutions based on generic platforms as the core and specialized components for delivering the customer experience!