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
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.
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.
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!
This is for all you FinTech entrepreneurs who would like to give the likes of Revolut, N26, Lunar and Klarna a run for their money. In this article I will demonstrate how to literally configure a new subscription to Bricknode as a core banking system to start managing current accounts within 30 minutes and at a fraction of the cost that legacy suppliers charge.
We love to empower entrepreneurs so they can bring new solutions to the market at lightning speed.
First I simply signed up for a subscription at www.bricknode.com and I got the logins for the system the same day.
Now, if I wish I can take care of everything myself or I can ask for help from the customer success team. Starting a current accounts business is extremely easy and this article explains everything that you need to do to get going.
As a first step you will probably already have established a relationship with a bank, or “Custodian” as we call it, where you have an account for client assets. This account has to be created in the Bricknode system as a custody account so the system knows where the assets are stored in the world outside of Bricknode.
Basically the only concept that you really have to understand before you start is what we call Account worlds and Dimensions, that’s it.
Here is an illustration.
The “Internal accounts” are your individual customers accounts, your partners accounts and could also be your own accounts, we call you the “House”. All the assets that reside in the Internal accounts has to be backed up by assets in the outside world, like cash at a client account at a bank.
In Bricknode Financial Systems (BFS) I have now received access to four interfaces, these are:
In the screenshots that follow I will reference which interface they are coming from with BackOffice, Partner, Customer or API.
Let’s have a first look at BackOffice to set up your first Custody account.
When you first log on you will come to the Dashboard, which you can easily customize with regards to the widgets that you see.
Locate the House View in the upper right corner.
To create a new account simply click on the Create button.
In the resulting dialog I will select Custody Account as the Account Type and I will name the account Bank 1 Client Assets, we are going to store the actual IBAN number of the custody account as a property on the account but it is recommended to include parts of the account number in the label so you can easily identify the account going forward.
Within Bricknode an account can hold any asset so we are not limited to having one account per currency, which a lot of traditional banks seems to be limited to because of legacy systems. We do have to set a base currency on the account though because this is used for calculating account returns in percentage terms, we do not have to deep dive into that here though.
If your bank/custodian limits you to one custody account per currency, no problem, just set up more custody accounts within Bricknode to reflect that.
Now the first custody account is created and I can progress to the next step.
Within Bricknode it is possible to manage any financial asset/instrument that I know of, in this article though I will only discuss traditional currencies. Any account can hold any type of asset but for currencies I want to configure a default custody account for ease of use and I also want to activate a certain number of currencies. Let’s navigate to System Data->Currency Management for this.
Within Currency Management I see that there are 33 currencies available by default but I have set a lot of them to Closed. I have the option to open currencies with different permissions to make them available to BackOffice, Partners and/or Customers.
To start with I have enabled four currencies and I use the same default custody account for all of them.
In this article I am working with a partner relationship where a user called Bricknode Partner is bringing in business and the first customer is called Bricknode User. Creating these users manually in Bricknode is very easy, simply navigate to User Management and create the users through the creation buttons.
Repeat the same process as above for creating the customer manually. Through your own customer facing apps or websites you would be doing this using CreatePersons in our API. If you use DotNet you should get our NuGet package where you have everything already implemented.
Let’s navigate to the customer within BackOffice and create a simple account. When you use the API you would implement the function called CreateAccounts for this purpose.
The transactions relating to deposits and withdrawals would probably come automatically from an integration with a payment service or the custodian but here I will illustrate a manual deposit. Click on the action menu for the account and select Deposit Money.
The resulting dialogue will default to the right custody account and set the Trade Date, Settlement Date and Value Date to today. I have entered a deposit of EUR 1,000.
The balance and the transaction will now show up in the Overview within BackOffice.
On the customer account I have set up a relationship with the Partner user.
And I have also set up a Power Of Attorney with “View” permission which will enable the Partner to see what is going on in the account. When you use the API you would implement the method called CreatePOAs.
On the dashboard, which the partner can arrange and add widgets to, the customer account can be seen and the related transactions.
By clicking on the customer the partner can drill down into the details.
If you do not have your own app or website ready you can let your customers log on to the standard customer portal where full interaction can take place and the content can be fully configured by the administrator together with branding.
The final step is the reconciliation of accounts that should occur daily. Remember the Internal and External accounts, the first I will check is the total balance of the Custody Account against the account statement that I get from my bank/custodian. To view this I will navigate to Positions->Cash.
Now I will filter on the transaction dimension Settlement and enter the balance date of what I would like to reconcile and also select Custody Account as the Account Type.
Here I see that EUR 1,000 is present in the custody account which should align with the account statement from the bank/custodian. If it does not I can click on the account and drill down into each transaction to see where the difference comes from.
Now when I know that the External account is fine I want to know if these assets are correctly spread out across Internal accounts too and for that I want to activate the Add-on that we call Reconciliation Manager. By navigating to the Marketplace I can request a trial of this Add-on right away.
The Reconciliation Manager is now activated and available in the House menu.
From the reconciliation overview I can drill down into each transaction if I wish by clicking on the House icon in the list.
Now I am all set and can continue doing business!
In order to simplify things and make this method (CreateInternalInstrumentTransferOrders) less error prone we have removed the two properties AcquisitionPrice and AcquisitionPriceAccountCurrency. Instead we calculate these from their corresponding value-properties: AcquisitionValue and AcquisitionValueAccountCurrency.
But don’t worry, we will not make any breaking changes for you but instead deprecate these properties in the API method in the near future. Be aware though that these properties will not correspond to any functionality.
AcquisitionPrice = AcquisitionValue / Units
AcquisitionPriceAccountCurrency = AcquisitionValueAccountCurrency / Units
We also let the user decide if they want the system to use a default behavior to set the Acquisition values or not. If the properties AcquisitionValue and AcquisitionValueAccountCurrency are submitted with any values apart from null we will use the formulas above to set their corresponding Acquisition prices on the order. However, if these values are submitted as null, the system will default these values on the order. The Acquisition values set on the order will be as follows:
The acquisition values on the transactions placed on the account where the asset is transferred from, will always be calculated from the acquisition price taken from its origin position.
The transactions on the account where the assets are transferred to will depend on whether the order will result in a technical trade or not.
If the order will result in a technical trade the acquisition values will be calculated from the current price of the asset that is transferred. An order that will not result in a technical trade will calculate its acquisition values from the current position and will therefore obtain the same values as for the transactions placed on the account where the asset was transferred from.
Time to address a hot topic regarding currency exchange in relationship to trading of various financial instrument types. There is no right or wrong here and there are many ways to do it, I will simply try to describe a few valid options in this article.
Ultimately it comes down to how the end customer, the investor, would like to interact with their investment activities and most preferences are possible to accommodate, it just comes down to development.
Let’s start with investing in mutual funds. This is the ultimate retail product and designed for ease of use with all the complexities taking place within the fund, that is part of why the fund must charge fees in one way or another to cover its activities.
No matter if the fund units are traded in USD, EUR or SEK the investor has become used to placing their orders in the currency of their own liking. If a German based investor wants to invest EUR 1,000 in a US-based mutual fund they should be able to place an order that details the final investment amount, and any currency exchange is expected to occur automatically.
The fund itself could publish different units for different currencies and then manage the currency exchange internally. Another common practice is for the broker, or the fund network that is used, to conduct a currency exchange, this usually introduces a larger spread between the bid and ask quotes for the currency exchange but on the other hand the amount is usually small. A clearer way to do it would be for the investor to first conduct a currency exchange where the right currency is obtained at the best possible exchange rate and then to use that cash to buy the fund units in the currency that they are traded. This cuts out the middleman from the currency exchange and becomes less costly. This is kind of the same thing as when you go to the ATM machine at the airport to get cash and it asks you if you would like the ATM operator to conduct the currency exchange or if you would like your custody bank to do it. To make that choice you would like to receive a comparison of what rate will the ATM operator give you and what rate will your custody bank give you, but you never get that option.
These two options will result in a difference in how the exchange rate will be reported on the trade note to the investor. In the “lazy option” where the currency is exchanged “automatically” in conjunction with the order the exchange rate could be reported on the same trade note as the trade. In the more cost-efficient option, the currency exchange is a separate event altogether and should have a trade note of its own.
Now let’s look at equities. As opposed to mutual funds, where the fund accepts the actual purchase amount and allocates fund units to the investor, an equity trade involves purchasing a number of shares. The shares are often traded in real time on a stock exchange so it cannot be known exactly at what price the trade will be able to execute. Because of this it is not possible to know exactly how much cash the purchase will consume so the most efficient manner is to first buy the shares and then conduct the currency exchange to cover the resulting deficit.
Enter the concept of “Cross currency buying power” and “Cross currency margin”!
To be able to make a trade the investor must have some sort of asset in their account which could be used for purchasing other assets. In the example above the investor might have deposited EUR 1,000 into the account and wants to buy shares of Apple which will consume USD. If the shares are currently trading at USD 125 per share and the conversion rate between EUR and USD is 1.22. The investor will be able to buy 9 shares of apple, consuming USD 1,125.
If settlement is made two days after the trade (T+2) the conversion from EUR to USD should be made before the settlement date or the account will have a deficit in USD, which by the way could be ok from the perspective of the broker since there are enough EUR available in the account to cover the trade, the buying power is there and the cross-currency margin to settle the trade.
From the perspective of the investor a currency exchange could then be made separately after the purchase is made because at that time it will be known exactly how much USD is needed. With regards to trade notes there will be one trade note for the trade and a separate trade note for the currency exchange, clear as crystal.
How about the other alternative, could the investor be offered to buy shares of Apple by entering an amount in EUR? Sure, the broker would then be able to make some extra money on the spread for offering this service. What would happen in practice in this case is that the broker will get the order to buy EUR 1,000 worth of Apple shares. The broker will first buy the shares without having to put up any cash since settlement will occur in two days. With the execution in hand the broker will perform a currency exchange for the required amount on behalf of the investor at an exchange rate spread.
The full EUR 1,000 will not be used since partial shares is not used here; fractional shares is a whole different topic though. On the trade note for the investor the equity trade will be shown together with the exchange rate that the broker gave to the investor.
Personally, I like decoupling the currency exchange from the trade, as an investor I like to have the choice and the information about the exchange rate so that I can decide upon it and as a broker I like to give full transparency to the investor. Again, no rights or wrongs, just a few different options.
The objective of the financial advisor site within Bricknode Broker is that it should be used as a complete financial management system for financial advisors who are tied agents to the financial intermediary who licenses Bricknode Broker. For this article I will call it the Financial Advisor GUI (Graphical User Interface). The goal of this GUI is NOT to offer a place for extensive performance reporting and financial analysis of managed portfolios, this could easily be accomplished by using our extensive API though. Instead it is a fantastic tool for keeping track of the income attributable to the financial advisor (fees) and order placement.
The financial intermediary who licenses Bricknode Broker can create a financial advisory company in the system and then a number of associated financial advisors. The advisory company will have a number of accounts that it owns for each advisor and the advisor will be linked to their accounts. This way the advisory company can keep track of how much fees are earned and owed to each advisor. The advisor can then log on to the Financial Advisor GUI to see how much money they have earned and request withdrawals to their own external bank account or if the advisory company should use the money to pay as salary to the advisor. Either way Bricknode Broker keeps track of the income and the advisor can manage their own cash flow within Bricknode Broker.
The customers will then be linked to their financial advisor who, depending on the permission levels, could place orders for their customers and manage all types of documentation and onboarding.
The chart below demonstrates the best practice setup for this use case.
There is a full guide available here for how to set this up in Bricknode Broker.
Our customers are adopting the use of our API faster than ever which makes us extremely happy! Even though we think our API is rather extensive we are developing new functionality at record pace and we also found a way of making new API releases disconnected from our other releases while moving towards full CI/CD.
As an example we just now released a new method in our API called CancelTradeOrders which can be used to cancel regular trading orders before they have been executed or received allocation from portfolio management. In connection with this we also released version 4.0.1 of our NuGet package which includes this new functionality.
As long as the introduced functionality does not introduce breaking changes or database changes we can do this stuff in a much faster way then before, let us know if there is urgent API functionality for Bricknode Broker that you need and we will have a look!