Unitlink.Net®
Unitlink.Net® is a generalised and very flexible unit linked core:
-
Builds on Insurance.Net® and thereby contains all the fundamental facilities from Edlund A/S'
other framework systems.
-
Unitlink.Net® can flexibly be integrated with value time-based systems (Life.Net®
or other policy systems).
-
Customer-specific fund providers can easily be fit in.
-
All portfolios at contract level can easily be divided by customer-specific criteria, e.g. tax code,
payment source basic form or the like.
-
Customer-specific requirements to trade cycles are also implemented easily and simply.
-
Etc. - see below!
Calendar administration
Unitlink.Net® supports, as standard, the creation of any number of trade calendars. It has automatic
calculation of common movable holidays (e.g. Easter). Calendars are used in the following connections:
-
Each fund is associated with a trade calendar so that Unitlink.Net® can determine which dates
prices are expected for.
-
Automatic opening and closing for completion of transactions is controlled by a calendar.
-
Calculation of future expected prices for use at simulated inclusion of future events.
Fund administration
Unitlink.Net® defines a fund by means of the following basic properties:
-
Fund ID (unique string).
-
Versioned information:
- Version date
- Description
- Fund provider
- Applied trade calendar for determination of trading days
-
Prices, where each price is defined by price time and value.
Additional information (e.g. the structure of a fund in shares or bonds) can easily be added customer-specifically.
These properties are displayed via a well-defined interface. As standard, Unitlink.Net® comes
with the following three implementations of this interface:
-
Funds, in which all fund information an all prices is registered from outside via integrations or screen
dialogues.
-
Constant interest rate funds, where only the start time and the yearly interest yield must be stated.
Subsequently, Unitlink.Net® will automatically set prices on all following
trading days according to the calendar selected.
-
Composite funds, in which the price is calculated on the basis of a weighted average of other funds.
In customer-specific code further implementations can be added, e.g. an implementation where fund information
is automatically fetched from an external system via service calls.
Unitlink.Net® sets no limits as to how often a price can be set for the individual fund.
Thus one is free to choose to have rates set daily, hourly or as required.
Posting of prices
Almost regardless which type of event (purchase, sale, reorganisation, etc.) is included, the posting of prices
will be an integrated part. The unit linked core makes it easy to define company-specific policies for how old
a price can be. By means of simple configuration, one can determine the following:
-
If only prices from the inclusion date can be used or if prices from previous dates can also be used.
-
If only prices set since the last closing for transactions can be used or if previous prices can also be used.
This option is particularly useful if there is closed for transactions briefly during the day.
-
Maximum age (in hours, minutes and seconds) of the price used. For example, it is possible to configure that
only prices of up to two hours old can be used.
In case of missing price, inclusion stops in a way that inclusion is automatically attempted again when a new price is set.
The inclusion time of such events will be the first time when there is a price available for all necessary funds.
Trade cycle
Unitlink.Net® supports four trade cycles:
-
Standard trade cycle. This method uses customer-specific code for determining the actual inclusion time of events
on the basis of the registration time. The typical use is scenarios where transactions must be included at 10 am the
day after the registration time. The day before the final inclusion the investment department will here be able to
identify accumulated transactions and set prices.
-
Immediate transaction. This method includes events at valid prices as per the registration time.
-
Antedated transaction (primarily for tests). This method includes events as if they were registered back in time.
This will primarily be used at testing so that a can pretend to register an event randomly back in time and thus
immediately see the result.
-
Postdated transactions. This allows the insertion of events that are not included until at a later time.
When the time arises, the event is included according to standard trad cycle.
In connection with customer-specific configuration of Unitlink.Net® it is determined which trade
cycles can be used currently.
Closing days, closing and opening times
Unitlink.Net® keeps track of when there is open and closed for transactions. There are three
options:
-
Automatic control of opening and closing for transactions. Based on a trade calendar which states closing dates,
a time which indicates at which time there must be opened and a time which indicates at which time there must be closed,
Unitlink.Net® itself opens and closes for transactions.
-
Manually open. There is open until operations closes or switches the control to automatic control.
-
Manually closed. There is closed until operations opens or switches the control to automatic control.
The possibility of manually closing quickly for transactions and all further activity can also be used as a so-called ’Kill Switch’.
Unitlink.Net® historically saves all times for opening and closing so that the inclusion time for antedated
events also can be calculated correctly.
Customer-spceifically it is possible per event type to state whether events of the type in question can be included outside of
open times. Typically it does not make sense to be able to trade outside open times, whereas e.g. reselection of future
distribution profiles for new amounts may very well be done at any time during the day.
Possibilities of inclusion
All new events can be included in three different ways:
-
Standard inclusion. This inclusion leads to the final inclusion according to current prices, trade calendars, opening
times and trade cycle.
-
Simulated inclusion. This inclusion leads to the result which the event is expected to end with at standard
inclusion. As opposed to standard inclusion, which can typically not be completed at registration due to closed trading
window or long trade cycle, simulated inclusion can always be completed. The result is based on expected prices and
expected opening times. The result can naturally not be saved, but can be used for display and for calculating the
sum of expected transactions after opening.
-
Test inclusion. This inclusion can (almost) always be completed, no matter if the trading window is closed
or open and no matter how old the last prices registered are. Is used for display purposes if standard inclusion
or simulated inclusion is not possible.
Unitlink.Net® additionally supports two variants of the above options:
-
Standard inclusion, but only for display. This inclusion works exactly as standard inclusion, except that the unit
linked contract can be rolled back immediately. Unitlink.Net® can hereby return the result of a standard
inclusion without updating the underlying unit linked contract.
-
Standard inclusion, but only if unchanged. This inclusion can only be done if the above inclusion method has been used
previously against the same unit linked contract. The idea is that the inclusion fails if the result differs from the
previous attempt, typically because new prices were registered in the intervening period.
The last variant is indispensable in situations where one wants to implement a web-based access whereby the customer can
register reorganisations. The administrative procedures are typically:
-
The customer registers a reorganisation.
-
Unitlink.Net® calculates the consequences, i.e. the new distribution of funds, costs, etc.
-
The customer is asked to accept the result of the reorganisation.
-
Before the customer clicks ’Approve’, new prices are registered so that the result is entirely different than the one accepted
by the customer.
-
The customer must get another chance to accept the changed result.
Full support of roll-back
In its nature, unit link is deeply real time-based as new events, as a rule, are only included at the registration
time (adjusted for trade cycle). Inclusion back in time would entail inclusion on old prices, which is naturally
not possible. Inclusion forward in time will entail errors due to missing prices.
Exactly this feature of unit linked systems makes it a business-wise (an thus also an implementation-wise) large challenge
to integrate value time-based policy systems with real time-based unit linked systems.
In order to ease (or actually enable) integration of the policy system and the unit linked system, Unitlink.Net®
offers full possibility of antedating and postdating events. At creation of an event it is thus possible to
specify that the event must be included in such a way that the customer is put in the same position as if it had been registered
at an earlier time or that the event does not have to be included until at a later time.
In order to support this full possibility of antedating and postdating, Unitlink.Net® performs two full inclusions
of all events. One inclusion happens in a strict real time-based concept where events can only be added at the end and where no
kind of roll-back or deletion of previous events is allowed. The other inclusion takes place in a value time-based concept where
there is (as in the life core) full possibility of roll-back, recalculation and deletion marking of previous events. Upon
completion of both inclusions, a comparison is made of the two results and any differences indicate exactly, and at the lowest
level, the compensation which must be given to the customer (positivt or negative) so that the customer is put in the same
position as if the event had been registered correctly in time.
Unitlink.Net® also offers to include events back in time in such a way that compensation is only
done if it is in favor of the customer.
Furthermore, the principle of double inclusion of events entails that it becomes simple to deletion mark or replace previous
events and thus place the customer in a position as if the previous event had not been registered. So, naturally, Unitlink.Net®
also supports this.
The compensation calculation, which is done by comparing the result of the two inclusions of an event, results in a number
of entries which, at the lowest level (i.e. per fund, per entry type, per tax code, etc.), documents exactly what the
company has to pay (or turn to account) in order to place the customer in a position as if the event had been registered
correctly in time.
In the value time-based inclusion trade cycle is handled in exactly the same way as in the real time-based inclusion. I.e. that
if e.g. one states that an event was supposed to have been included on 12 December at 00:00, and if 12 December is a Saturday
and there is opened for transactions on Monday 14 December at 09:00 and if immediate transactions are used, the actual value
time is Monday 14 December at 09:00.
Mass operations
Unitlink.Net® uses the concept ’mass operations’ about operations which must be performed on all unit linked
contracts.
Example: A fund has to be closed. In all unit linked contracts the holding of the fund in question must be transferred to
other funds.
Naive implementation: Offhand it would be obvious to solve the above problem by a run which goes through all
unit linked contracts and performs a reorganisation of the unit linked contracts in which is a holding in the fund
which is to be closed. However, there are a number of problems to this approach:
-
The run has to be executed as close as possible to the time when the reorganisation specifically is to be made.
-
Even though a unit linked contract at the execution time does not have holdings in the fund in question, the contract
may very well be assigned holdings in the fund retroactively. In such cases the run has to be executed again.
A better implementation: A run is implemented which goes through all unit linked contracts and inserts an event
for reorganisation whether or not the contract has a holding in the fund which is being closed or not. This solution
is stable against the problem with roll-back in the naive implementation, however, there are still problems:
-
When the run for reorganisation out of the fund which is being closed has been executed, a new unit linked contract is
created retroactively. This unit linked contract will not contain the reorganisation event and will thus potentially
risk building a holding in the fund which is being closed.
The correct implementation: The 'better implementation' above can be done even better by doing the following:
-
Information about what must be done when, for all unit linked contracts, is registered in a special central register.
-
The central calculation algorithm in Unitlink.Net® is designed in such a way that information from the
above register is automatically converted into events which are included on a par with other events.
-
The service for current inclusion of outstanding events is designed so that all unit linked contracts are affected
(loaded, calculated and saved) each time the real time of an entry in the above register comes.
This 'correct implementation' is exactly what mass operations are! More specifically, mass operations are charactrised by
the following:
-
A register, in which mass operations can be registered. Each mass operation is characterised by an ID, version
number, type, real time, value time and specific information for mass operations which are to be repeated
monthly or annually.
-
The register can be expanded with a customer-specific code so that it is possible to indicate which fund is to
be closed, monthly costs or other information which is specific to the underlying operation.
-
Generally, this register should be updated so that mass operations are defined before the desired inclusion time.
However, Unitlink.Net® allows retroactive registrations of mass operations.
-
The central inclusion algorithm in Unitlink.Net® is designed so that outstanding mass operations
are merged with other events. As a rule, the resulting events get a real time which matches information stated in
the underlying mass operation. If this is not possible due to other later eventes, the value time of the resulting
event is set at the value of the inclusion time as indicated in the mass operation.
The service for current inclusion of outstanding events also handles mass operations. Mass operations are thus
automatically included without the use of any special runs.
Simulated infinite speed
Ideally, Unitlink.Net® should be implemented so that the following principle applied:
-
All operations musk be completed immediately when the business time comes.
Naturally, is is physically impossible to fulfil this principle in hardware with finite speed and capacity (no matter
how high the speed and how large the capacity are). Therefore, Unitlink.Net® is implemented in
such a way that the following principle applies:
-
Where at all possible, Unitlink.Net® must act as if all operations are completed immediately
when the business time comes.
Among others, this principle can be seen in the following modes of operation:
-
Assume that during the night 100,000 reorganisations have been registered. Further assume that at 8:55 am prices are set
for all funds and that at 9:00 am the system opens for execution of events. Unitlink.Net® will
automatically initiate the execution of the 100,000 outstanding reorganisations from 9:00 am. In practice, this will
take some time depending on available hardware. Then assume that the execution of all outstanding reorganisations takes
10 minutes and that already at 9:05 am new prices are set. Regardless of the new prices which are set before all
reorganisations are executed, all 100,000 reorganisations will be executed with the inclusion time 9:00 am and at the
prices which were valid at that time.
-
Based on the above example: If a unit linked contract, which still has an outstanding reorganisation, is opened in the
period between 9:00 am and 9:10 am, this event will be just-in-time-included so that to the case administrator
or the end customer looks as if the event was actually included at 9:00 am.
-
If one closes for the execution of transactions at a time when there are still already registered, but not completed,
transactions, these will be executed as they have not been executed simply due to physical limitations to the
hardware. Thus, if one, in the top example, manually closes for transactions at 9:00:01 am (so that there was only
open for one second), all 100,000 reorganisations will still be executed with effect from 9:00:00 am.
Holding and entry level
Unitlink.Net® requires that the holding at contract level is divided into fund level. In addition,
it is company-specifically very easy to expand this division so that it is also done by tax code, payment source,
basic form and/or other company-specific criteria.
Entries follow the same division as above. In addition to that, entries are also divided into the following fields:
-
Entry type (Purchase, sale, yield, broker's fee, etc.)
-
Indication of which event that caused the entry.
-
Indication of which calculation step that caused the entry. Possible calculation steps include estimation of yield,
replacement of previous event, actual event calculation, rounding off and compensation
calculation.
Booking is done in units as well as in value. This means that each entry enters a change in units and a change in value.
However, yield entries never enter changes in units!
PAL calculation
Unitlink.Net® continually calculates latent PAl and makes it extremely easy to implement the event
for settlement of PAL. The event for settlement of PAL is typically company-specifiv and thus not fully implemented
in the core.
Rigid internal checks
It is of the utmost importance that events are included correctly and consistently. The following checks are therefore
always carried out in connection with inclusion of events. If one of the checks fails, the whole inclusion fails.
-
The amount of entries generated in connection with inclusion of an event must reflect the change exactly - both in
the number of units and in value - since the last event. Unitlink.Net® checks that this is
fulfilled at the lowest level, i.e. per fund and other criteria which holding and entries are divided into (tax
code, payment source, basic form, etc.).
-
The amount of entries which are generated at the real-time layer and the value-time layer, respectively, in connection
with inclusion of an event must balance upon completion of compensation calculations. Here, Unitlink.Net®
also checks that this is fulfilled at the lowest level.
-
The number of units or associated value must, after inclusion of an event, never become negative. If this happens
the inclusion is error-listed by Unitlink.Net®.
Ongoing reporting of accumulated holding
Unitlink.Net® keeps constant track of accumulated holdings at portfolio level. The total holding in
units and in value can thus continuously be viewed on a screen page which is automatically updated every two seconds.
In short intervals the total holding in units and in value is sampled so that it is also possible to get a historic
overview of the development. The frequency is typically once a minute, but can be configured company-specifically. This
development can also be viewed on a special screen page.
Reference implementation
Edlund A/S has developed a reference implementation of Unitlink.Net®, which serves the following purposes:
-
Based on the reference implementation, all Unitlink.Net®'s facilities can be demonstrated. The
reference implementation contains common events, e.g. new business, purchase, sale, reorganisation and rebalancing.
-
Based on an adjusted copy of the code of the reference implementation, company-specific solutions can quickly be delivered.
-
A very large collection of automated test ensures high quality in the code base of Unitlink.Net® –
now as well as in the future. Our build server builds the reference implementation up to several times a day, and
in connection with each build is built, among other things, a holding of 100 unit linked contracts with 2,000 events
on which a great number of tests are performed.
The client for Unitlink.Net®
The client is fully implemented in Windows Presentation Foundation (WPF), which enables efficient and stylish dialogues.
The client is, just as the rest of the clients in our framework systems, fully expandable in connection with customer adjustment.
The client for Unitlink.Net® is, just as the clients in our other framework systems, fully localisable.
Select screens from the unit link client are displayed in the following. Click the pictures to view them in natural size.
|
In this dialogue, it is possible to control the opening and closing for transactions. This dialogue is the first one one
sees when one opens the operation dialogue of Unitlink.Net®. From here it is possible to use 'Manually
closed for transactions' as a kill switch.
|
|
Here is an example of editing of the trade calendar. By clicking the individual button next to each date, one can
indicate whether the date is closed that year, whether the same date is closed every year, or whether the same
weekday is closed every week. For holidays (including holidays that fall on different dates every year), it is possible
to indicate that the holiday in question is a closing day every year.
|
|
Overview of accumulated holding for the total portfolio of unit linked contracts. The page is automatically updated
all the time as new transactions or reorganisations are executed.
|
|
Complex example of overview of included events. In this case, event number 18 has been antedated at the same
time as it replaces event number 17. Event number 19 replaces to previous events, namely numbers 12 and 13.
|
|
screen displaying information about included event number 18.
|
|
Clear overview of the changes to a unit linked contract. Note that the investment profile does not change from
version to version, whilst the holding is changed at each event. By clicking the individual overview, exactly
the lines containing changes in the version in question are displayed. In specific company-specific implementations
there will be a lot more information.
|
|
Ad hoc calculation of effective yield for any period can be made directly from the individual unit linked
contract. The effective yield is calculated by use of iterative zero-finding.
|
|
Unitlink.Net® can export all information about a unit linked contract in XML format. The
XML document of a given unit linked contract can be displayed on a special tab in the client.
|
|
All events which can be registered via the client are registered via a wizard (Guide) where this is the
first page. It is here possible to see how to select event type, any previous event which is to be
replaced, compensation calculation, real time (only for testing purposes), value time, etc..
|
|
All events which can be registered via the client are registered via a wizard (Guide) where this is the
last page. The intermediate pages are specific to the selected event. The last page shows what the
result will be. In this case, final inclusion is not possible, for which reason a simulated inclusion is
displayed (hence the watermark).
The many tabs indicated that there is a lot of information which can be examined or validated before the
event is executed.
|
|
Same screen as above, but here one sees the tab for which entries will be generated. Again, it is a
simulated calculation on simulated prizes, for which reason it must be expected that the final inclusion
will be slightly different.
|
|
Same screen as above, but now the tab documenting the change in value compared to the latest event
is displayed.
|
|
This page in a unit linked contract displays an overview of outstanding events. The overview will typically
be empty, but in this case, a postdated event is waiting for the future!
The event will automatically be included when the future (in this case 20 March 2009) comes.
|