S
UMMARY
1 Introduction ... 3
1.1 Financial Market ... 4
1.2 Banks Finance Area and informatics technology, the CAD IT solution ... 4
2 Athena Consulting Strategy ... 6
2.1 The business idea ... 7
2.2 Alliance with Mind Srl ... 7
2.3 Terms of Agreement ... 10
2.3.1 Premise ... 10
2.3.2 Mutual Commitments ... 11
2.3.3 Economic relations ... 12
2.3.4 Further evolutions of alliance ... 13
2.4 The products – Sinfonia suite ... 14
2.5 The realization chain ... 16
3 Design ... 17
3.1 The software modularity ... 18
3.2 Standard working process architecture ... 21
4 Development ... 22
4.1 The Athena methodology ... 22
5 Sinfonia suite ... 26
5.1 SSI - Standard Settlement Instruction ... 27
5.1.1 Directions for use... 27
5.2 Tick - Settlement activities reconciliation ... 28
5.2.1 Directions for use... 28
5.3 Norma - Atypical events manager ... 29
5.3.1 Directions for use... 29
5.4 Money - Cash Accounts Security area ... 30
5.4.1 Directions for use... 30
5.5 Cash - Securities area cash-flow ... 31
5.5.1 Directions for use... 31
1
5.6.1 Directions for use... 32
5.7 Gest - Management Control development ... 33
5.7.1 Directions for use... 33
5.8 Note – Services Billing development ... 34
5.8.1 Directions for use... 34
5.9 Join – Reconciliation ... 35
5.9.1 Directions for use... 35
5.10 Trasla - Syntactic Transformer ... 36
5.10.1 Directions for use... 36
6 Focus on Info and Gemma... 37
6.1 Gemma – Corporate Actions messages from custodian manager ... 37
6.1.1 Users ... 38
6.1.2 Directions for use... 39
6.1.3 Functional characteristics ... 39
6.1.4 Functional Description ... 40
6.1.5 Application architecture ... 44
6.1.6 Data definition ... 45
6.2 Info - Information Providers Filter ... 47
6.2.1 Users ... 47
6.2.2 Directions for use... 48
6.2.3 Functional characteristics ... 48 6.2.4 Functional Description ... 50 6.2.5 Application architecture ... 52 6.2.6 Data definition ... 53 7 The commercialization ... 55 7.1 Customization... 55 7.2 Pricing strategies ... 59 8 The deployment... 61
8.1 The activities mapping and the support cards ... 61
9 Conclusions ... 63
Acknowledgments ... 64
2
« Tanto casino per ritrovarmi seduto
ad un tavolino con Beppe e la Luisa »
Adolfo, Novembre„09
3
1 Introduction
The thesis treats all the changes incurred to Athena Consulting during the strategic develop-ment it achieved and that it has led in order to impledevelop-ment a software developdevelop-ment chain to support the finance area of banks and financial institutions.
The company, founded in 2004 and till 2009 working in the financial consultancy field, de-cided to become a software house capable of designing, developing and marketing its prod-ucts by relying mainly on the skills of its employees – especially the management – and through the alliance with Mind Srl, a company operating in the Athena target market as software trader.
This work is divided into 10 chapters, summarized as follows.
Chapter 1 offers an introduction describing the context related to the financial market and products now existing to support the banks finance area.
Chapter 2 speaks about Athena Consulting and the strategic choices that have characterized its past year, including the alliance with Mind Srl and the decision to enlarge its business. In Chapter 3 are discussed the design choices adopted by the technical director to create a suite of products geared to the effectiveness and efficiency achieved through the modulariza-tion of software structure.
Chapter 4 describes the products development chain as it has been designed by the technical director following the Athena methodology, programming meta-language based on Visual Basic code able to generate portions of code causing, thus, a significant reduction of pro-gramming time at the expense of a greater rigidity in the choice of patterns.
Chapter 5 describes the full suite of products that the company, in partnership with Mind Srl, has chosen in order to penetrate the market of supporting finance area products.
Chapter 6 and Chapter 7 describe two products specifically since they are considered "peak" for Athena and Mind management: Gemma, product to manage Swift messaging and Info, realized to support the alignment of messages coming from different info-providers (i.e. Bloomberg, Reuters, Borsa etc).
Chapter 8 describes how to approach and control the deployment activities during new prod-ucts installation and starting.
Chapter 9 treats about the logics behind the marketing choices to advertise and sell the new products.
4
1.1 Financial Market
The financial market is in the place where financial securities are traded and its own negotia-tion reference is the stock exchange. It mainly includes stocks and bonds issued by compa-nies, investment funds and derivatives.
The main economic entity operating in the credit domain is the bank. Credit is defined as an economic transaction where an entity provides resources to another one under the condition that the former is not reimbursed immediately but, generating a debt, which the latter, as monetary or resource settlements. repays the former at a later date.
While banks cater the needs with more or less short term monetary transactions, the stock exchanges and other financial institutions through financial transactions, specifically focus on companies and help them in the medium and long term, by making durable investments. For instance, an enterprise that requires long-term funding can contact a financial institution to obtain a loan or to issue shares and bonds. Even the financial institutions typically collects some of the capital he that it lends by issuing debt securities (usually bonds).
In any financial market, exchanges are facilitated by the intermediaries, professional to help bridge supply and demand of securities (banks, brokerage companies, institutes).
The financial market is broadly divided into two types:
primary market: that deals with the issue of new securities;
secondary market or aftermarket: where previously issued securities and are bought and sold; the place in which secondary market takes place is the stock exchange.
1.2 Banks Finance Area and informatics technology, the CAD IT solution
In banks and credit institutions, the “Finance Area” typically includes all the activities re-lated to the management of financial securities in terms of front and back-office procedures, brokerage, accounting and governance and overall control.
To help support this area, a leading product, called "Area Finanza” is in the offering from CAD IT S.p.a. This product currently dominates the market and has a wider acceptance in comparison to its competitors (it is used by 72%1 of Italian banks as back-office management software and by 50% for front-office management).
The popularity of this product in the Italian banking system comprising 840 banks with 29,4002 branches clearly shows that the product incorporates best practices of the sector.
1
Source, Cad IT overview at Milano Stock exchange, 2008 2 Source, Banca d‟Italia report, 2008
5 Although widely used for the internal procedures, "Area Finanza" provides a multitude of services and this results in some critical elements in terms both of services portfolio and per-formances.
Moreover, as a consequence of its complex features, this product sometimes appears hard to change and requires highly invasive techniques. The costs involved with a product of this type therefore includes, a high consulting costs during design, configuration, installation and maintenance processes in additionto the cost of first purchase.
6
2 Athena Consulting Strategy
Every since it was founded in 2004, Athena Consulting S.r.l. (Ltd) has focussed on proving consultancy services to other businesses in the financial informatics domain. This involves following its customers during the stages of analysis and selection of the most suitable soft-ware solutions in different contexts, managing highly design complexity issues, and collabo-rating during the development, implementation and monitoring phases.
Therefore, the core competencies of Athena, mainly include the expertise of its founders and employees, and the wealth of consulting experience gained working in very specialized in-formation technology projects to support bank operations in years.
In 2009 the company decided to change its strategy and enlarge its business by evolving from a pure consulting company to a real software house with its own products. This move resulted in a split business model spanning commercial and consulting domain among them-selves distinct. The main thrusts for the strategy change are summarized as follows:
During the consultancy projects undertaken in his life, Athena feels resentment and significant inefficiencies in the various systems supporting finance area;
Growth in terms of economic strength and the awareness of having the appropriate skills, made a case for expanding the business as it was now possible to reduce risks coming from the broadening of the service spectrum and from a complete business model overhaul.
Given the fact that there were major software vendors – CAD IT software firstly but even others –already on the market, the management still decided to enter the market by offering
Area Finanza complementary products by relying on the following strengths:
Quality of products; Innovation orientation;
Short design, development and installation times; Low prices.
The decision to enter the market of production and management willingness to make this a core competence led a huge strategic shift. Firstly, competitive priorities changed signifi-cantly.
7 In fact, company‟s focus shifted from mainly handling technical and project management oriented aspects, fundamental to operate in the informatics consultancy domain, to a multi focusing involving these objectives:
Quality; Reliability;
Reasonable design, development and installation time; Costs reduction;
Market adaptability capacity by identifying the gaps left by CAD IT.
Due to the managerial constraints involved in making an effective demand forecast, espe-cially during early years, Athena had to adopt an extremely slim business model structure composed of senior management, some mid-level managers and occasional collaborators re-cruited on a project by project basis (Figure 1).
2.1 The business idea
The targets set by the new Athena management structure, based on the business model pro-posed by the management, are shown as follows:
To provide niche solutions to the market: o non-invasive;
o able to solve a specific problem;
o easy to be installed both technically and organisationally; o low cost (with limited budget impact);
o complementary to the already existent products; o technologically advanced (web-oriented).
Create references to deal with increasing complexity problems.
2.2 Alliance with Mind Srl
"Even the best product in the world may remain unsold if there isn‟t an effective sales force”3.
The Athena management realized the need to institute a commercialization component that was not already available in the company, to help enhance the exposure and create awareness for the products it was going to develop.
8 This has resulted in the collaboration with another company, Mind Srl which was dimen-sionally limited but was already oriented to help facilitate third part products commercializa-tion and moreover it was also geographically located in the Athena target market area. The collaboration was reflected in the definition of a partnership agreement with Mind, tem-porally defined, in order to achieve synergy and to open up the market for products that Athena was realizing.
To achieve this collaboration Athena and Mind reviewed their organizational structure – even maintaining their own brands and formal independence – to continue utilizing the brand image built over the years and without dispersing the assets already acquired in terms of functional competences (Athena) and customer portfolio (Mind).
In the partnership agreement, the rules of cooperation governing the defined period are listed and the foundations for a future collaboration considering an eventual merger of the two companies into one company with a complete structure.
Before embarking on this alliance, which forced it to substantially revise its corporate struc-ture (Figure 1), Athena examined its costs to assess the feasibility of realizing its own sales force but the high degree of expertise required and therefore the training costs that would come along, the need to have references even to merely be heard on the other side, has made it clear that outsourcing the tasks or establishing an alliance would have been more suitable and effective.
The factors considered by Athena to help choose the company to support the commercial and marketing activities can be summarized as follows:
1. Operator general characteristics in terms of: Financial solidity;
Strategic alignment with Athena; Innovativeness;
Quality of service; Operator attraction.
2. Specific characteristics related to the skills inherent with finance area: Technical skills;
References; Trading ability;
9 The selection and choice of activities that led Mind Srl to be identified as the right interme-diary fitting Athena purpose can be summarized as follows "to advertise, in a focused way
and help the sale of Athena‟s new products”4.
The partnership agreement, signed in July „09, gives an organizational structure consisting of two business units controlled by the general management:
Technical and Research and Development; Sales and Marketing.
The new partnership organizational chart presents the general direction managed through a supervisor jointly chosen by the partners, the technical and R&D activities managed by Athena and the sales and marketing activities managed by Mind Srl.
Figure 1 - Athena Consulting Organizational chart since July „09
10 The partnership goals divided among Athena and Mind are summarized as follows:
Athena realizes, in addition to the products, works on: o Product descriptive functional documentations; o Individual products and suite architectures; o Informative brochures;
o Presentations.
Mind strives, instead, to search for customers and performs presentations supported, where appropriate, by Athena technical director.
2.3 Terms of Agreement
In July „09, the two companies signed an informal agreement whereby they decide on a shared common goal of penetrating the target market.
The contract is divided into sections and its analysis is useful for understanding and evaluat-ing the partnership orientation. Below the agreement structure:
Premise;
Mutual commitments; Economic relations; Further evolutions.
2.3.1
Premise
In the premise Athena and Mind core competencies are highlighted and the agreement‟s broad outlines are defined. In conclusion, agreement duration is timed and the conclusion also presents the possibility of further partnership changes.
"Athena is a company able to provide consultancy and software products related within finance area.
Mind is a software marketing company and it is interested in establishing a busi-ness relationship with Athena and through this relationship Athena provides Mind consultancy and software products to be advertised in the financial market.
The software to be developed is a part of the banking finance domain jointly identi-fied with Mind.
11
Although the agreement is initially limited to 12 to 18 month time horizon, since now the parties express an interest to investigate the possibility, after the first pe-riod, to merge and create a company that has the ability to produce and provide: consulting, software and marketing”.
2.3.2
Mutual Commitments
This part of the contract describes the roles belonging to either part in terms of commitment towards the partner and the interaction model. It also defines the procedures for decision making.
"Athena is committed to:
Planning and development of software products already selected in
agreement with Mind and coordinate with Mind for planning and looking at prioritizing aspects;
Develop software that manages, especially, the costs and components
structure in order to build products or components easy to be reused;
Define with Mind the marketing strategies for each product, the strategies
should aim to achieve business and IT skills development;
Deal with the products license terms;
Examine the ability to definitively sell the products source code to Mind.
While, Mind is committed to:
Identify, through meetings, requirements and information needs from
fi-nancial institutions and to share these with Athena;
Develop a plan to make trade visits to promote the products already
se-lected with Athena vigorously;
Support Athena in the preparation of development plans and related
pri-orities to be assigned to each product;
Deal with Athena the products license terms, as a priority;
Define with Athena the products marketing strategies that aim to achieve
12
2.3.3
Economic relations
The third agreement section distinguishes three different scenarios, related to the ownership of developed and financed products, which may result from the relation:
"The products developed by Athena can be:
1. developed and funded by Athena: in this case they remain property of Athena and Mind must just keep the focus on selling the product with the agreed conditions;
2. if the product is funded and developed by Mind and Athena with 50% con-tribution from each partner: the property and the incoming revenues are 50% equally divided;
3. if the product is 100% developed and funded by Mind: the product is under Mind ownership and it can sell them for its revenues entirely. Mind is committed, in this case, to commission Athena any consulting, deployment and maintenance projects for this product."
Then, the proceeds allocation modality, are defined relating to the different contributes given by the partners:
"The sharing of revenues will follow these criteria:
For exclusive Athena property product are due to Mind: o 20% of software license agreement;
o 20% of the maintenance contract;
o 20% of the deployment project proceeds performed by Athena. For joint ownership (50%) between Mind and Athena are due to Mind:
o 50% of software license agreement;
o 20% of the maintenance contract (maintenance is performed by
Athena);
o 20% of the deployment project proceeds performed by Athena. For exclusive Mind property are due to Mind:
o 100% of software license agreement;
o 30% of the maintenance contract (maintenance is performed by
Athena);
13 The order fulfilment strategy as "assemble to order" (see 3.1) is defined by the following:
"The products will be definitely developed just when it has an absolute place on the market."
Ultimately, appears the formalization of market penetration goal, for the product introduction phase, obtained through sales with almost zero margins:
"The companies mutually agree to apply for the first sales particularly favourable conditions for customers, especially if opinion leaders5, to promote as much as possible their own diffusion.
In general “particularly favourable conditions” are those that aim, at least, to cover the costs”.
2.3.4
Further evolutions of alliance
The agreement is concluded by explicating the ways in which, eventually, the two com-panies could have subsequently run into a full merger.
"If, after 12/18 months Athena and Mind wish to merge to create a larger com-pany with the possibility of wider commercial offering then:
The either equipment will be transferred at book value6 ;
The software asset will be defined from the development cost plus 10% due
to year or portion of the year without taking into account the depreciation occurred."
5 Opinion leaders are experts whose positive opinion on product could convey the image and particu-larly is bigger than any other type of advertising because of their influence and reputation.
14
2.4 The products – Sinfonia suite
Once adopted the new corporate structure, Athena and Mind jointly defined the detailed product portfolio characteristics whereby the new structure would have faced the market. The phases of analysis and product identification were carried out jointly by Athena and Mind executive: the general management, marketing and technical units.
In the new context, product development is influenced by attention to brokerage, administra-tion, regulaadministra-tion, accounting and reporting to supervisors. So, these became the main activi-ties that need to be supported.
Consequently, 12 products, grouped under the name “Suite Sinfonia” (Symphony suite), were defined in order to “support all activities involving the finance area and designed to solve
specific problems with a very effective cost/performance rate”7.
In order to define the products the management had considered the finance area structure for banks in general (Figure 2).
The aim of covering all the functions in the package led the product domain being divided into five main groups.
Below a schematization preceding the individual description of each product (see chapter 5).
Smart, reference area
Products designed to improve the quality of information, managed by corporate ref-erence, reducing meanwhile the need for repetitive manual activities;
Back area, back-office
Products that streamline the daily operational activities to minimize repetitive man-ual tasks that could consume time and qman-ualified resources and can lead to managerial inaccuracies;
Control, governance and control area
Products intended to efficiently support operational activity by minimizing repetitive activities related to cash flow, balancing and billing management;
Join, representation area
Products for daily or immediate reconciliation both of accounting and informatics environment, with the ability to control and manage the alignment of two or more electronic environments.
15 Trasla, transformation area
Product to process data in order to manage company integration system.
While this suite is able to fill gaps left by the various management systems to support the fi-nance already on the market, the long-term goal of Athena is to become the market leader creating software that addresses these inefficiencies.
Back-office
Reference
Front-office
Links with external worlds
Web applications
Securities master db
Info providers
Markets Custodian
Government & Control Transformation area
Representation
Control Settlement instructions Trade account Market law Prices Management system Market hall ControlPrimary market Complex
Administrative Elementary Transformation area Reporting Risk management Cash management Management control Balancing Accouunt Taxation Depositors Custodian Owners
16
2.5 The realization chain
The definition of the contract agreement with Mind and the effectiveness of the products re-quirement identification phase have enabled the realization of products, which would then be followed by precise marketing operations. The suite development chain is constituted by 5 phases (Figure 3):
Design Basic
development Customization Deployment
Starting and Monitoring
Figure 3 - Realization stages
1. Design: once the product requirements are defined by various sources (management mainly but also customers, consultants, magazines, etc..), the most appropriate prod-ucts structure is identified considering the efficiency mission as explicited by the management;
2. Basic development: this leads to the full development of products skeleton as to later make any customization rapid;
3. Customization: in this phase, once an order from the customer is acquired, the de-veloped product is extended and modified to satisfy customer specific needs;
4. Deployment: in this phase, the product is delivered and installed on the customer target system;
5. Starting and monitoring: finally, the new application starts working and monitoring operations are led to check for malfunctions or bugs related to any integration sys-tem issues.
17
3 Design
Software for banks are typically characterized by a strong customization and long develop-ment, installation and configuration time and, often punctuated by changes on top manage-ment where they must be placed, are characterized by considerable delays.
Typically, software are made through a succession of activities in which designs and devel-opment are based on specific use requirements and are then called custom or ad hoc.
The duration of time in finding a solution, development and installation of custom products is a major factor that leads the management to avoid implementing innovative projects on information systems and therefore generating a significant immobility.
Athena, realizing the problem and by using its skills and ability to understand market needs, choose the way of application packages, software ready to be used that require more or less complex, however just activities of configuration and parameterization.
This pattern makes Sinfonia products more attractive for potential customers and addition-ally it allows to change designing and planning activities with more standard (and therefore less expensive for Athena) parameterization, configuration and management of interaction between package and system.
During this development model Athena decides to exploit its leverage competitive advan-tages, "Sinfonia products design and development must be made in push logic, as the
cus-tomer's order must give way to the customization stage that has to be realized in a period not exceeding two months8”.
A solution of this type requires the company to focus on two fundamental design aspects, modularity of software components and the decoupling of development and customization phases.
The aim of having customization as late as possible (concept of postponement9 already
known in economic and production-oriented literature) corresponds perfectly to the pursuit of a lean model Athena has tried to give, in this sense it is not advisable to invest resources in developing solutions not necessarily able to be sold.
The possibility to manage the activities in this way depends on the awareness in the field of software products for large integrated systems such as banks. In fact, the amount of time cus-tomers are willing to tolerate is long due to the high risks, even opportunities10 arising from a failure or a success based on the product installation in the company system.
8
Source, “Briefing July 2009”, Milano, Athena Consulting
9 The postponement is a technique that falls between the disciplines of design for logistics and aims to pro-designing of processes and products so as to postpone product differentiation at the latest. The ad-vantages are that if they take high flexibility, reduced delivery times and ease of change.
10
ICT investments are get used to be called iceberg investments because of their opportunities diffi-culty to be clearly defined previously.
18
3.1 The software modularity
The design goals of Athena for the code are to provide the best user functionality, as quickly and as cheaply as possible reaching the best balance between:
user satisfaction;
expansion of the program easiness; comprehensibility of used solutions;
easiness of managing the increasing application complexity.
Athena translates these objectives into a design model based on a modularity idea of compo-nents composing the products. The model is described below:
Starting from the definition of 12 products (chapter 5) and their requirements it was rather assumed a number of software objects (modules), common to all applications and deputies to perform different tasks (Table 1 - Role and function of development moduleTable 1). Athena meets these basic needs by an effective and efficient design model:
reusing of parts already made;
the ability to extend a program without having too heavy changes.
Both these aspects are partly motivated by faster development and largely on the higher quality of resulting product:
reusing successfully used component allows reducing failure and loss of control risks;
minimizing number of changes allows to reduce the risk, that a functionality exten-sion is reflected in a malfunction of already implemented parts.
Everything is finally reflected in better efficiency in terms of both time and cost. Obviously, writing reusable and extensible code is not easy but it is one of Athena‟s main strength so that, in this direction the management is actually going to materialize the first investment.
19
Table 1 - Role and function of development module
OBJECT ROLE FUNCTION
Analizzatore
(Analyzer) Treasury position manager Manages cash flows analysis on different currencies. Azionatore
(Actuator)
Decisions table manager (conditionated action)
Manages the execution of an action against the occurrence of a condition.
Collezionista (Collector)
Collector of data used on the activities
Manages, during the conduction of a batch activity, for each in-put and data that should be treated, the fields necessary to per-form the activity.
Condizionatore
(Conditioner) Conditions governor Check the “WHERE” SQL conditional strings. Conservatore
(Conservator)
Coordinator of records mainte-nance
Manages the back-up, restore and maintenance functionalities for each data instance.
Correlatore
(Correlator) Correlation governor
Manages correlation associated to input files during a batch ac-tivity.
Descrittore (Descriptor)
Manager of client input route description
Manages the representation of all the routes gave by the client and needed to feed the products.
Dottore (Doctor)
Pathological situations
ana-lyzer Manages diagnostic solutions available for each product.
Formulario
(Formulas form) Formulas governor
Manages formulas calculation performed during the product ac-tivities.
Giornalaio (Newsagent)
Swift messages receiving log
manager Manages the receiving log of the Swift message succession.
Governatore
(Governor) Governor manager
Manages the history of the activities performed by the product on the time.
Guardiano
(Guardian) Governor of used field
Manages, while a batch activity is performed, the abstract of fields needed to realize it and the employment of each of them. Invariante
(Invariant) Governor of the constants used Manages all the constants defined for a product. Normalizzatore
(Normaliser) SWIFT message normaliser
Manages the translation of SWIFT messages in an internal work-ing syntax.
Posizioniere
(Positioner) Treasury positions maintainer
Manages instances of data useful for analysis of cash flows for the various currencies
Simulatore
(Simulator) Simulation stage s manager
Manages simulation session (data entry, execution and analysis of results) of configuration activities in the products.
Sopportatore
(Tolerator) Rules of tolerance governor
Manages all the rules of tolerance configured to carry out an ac-tivity.
Stampatore
(Printer) Governor of reporting Manages the customization of reporting pattern in the products. Stralciatore
(Extractor)
Governor of activities to extract information
Manages the obtaining of tracks taken from record data in-stances.
20 A comparative analysis of product requirements and hypothesized objects gave evidence that the whole Sinfonia suite realization was feasible by using just 17 common objects (64% av-erage reusable) and a limited number of specific modules (3).
The most interesting aspect is that, on average, it is estimated that 70% of products consists of modules and therefore:
realizing the 20 items can cover a large nucleus of whole 12 applications;
on average, making a product, with steady condition, costs only 30% of remaining specific software realization.
The advantages in term of efficiency for the realization chain are evident. The projects and their use in various products are represented below:
Sinfonia suite is initially directed only to banks, since the products are realized in a modular and integrated way, as seen, this makes a future extension possible to Insurance, Brokerage companies, Investment Management Company (IMCO) and also industry in general.
OBJECTS/
PRODUCTS CASH GEMMA GEST INFO JOIN MONEY NORMA NOTE QUADRA SSI TICK TRASLA RR
Analizzatore X X 17% Azionatore X X X X X X X X X X X 92% Collezionista X X X X X X X X X X X 92% Condizionatore X X X X X X X X X X X 92% Conservatore X X X X X X X X X X X 92% Correlatore X X X X X X 50% Descrittore X X X X X X X X X X 83% Dottore X X X X X X X X 67% Formulario X X X X X X X X X X X 92% Giornalaio X X 17% Governatore X X X X X X X X X X X 92% Guardiano X X X X X X X X X X X 92% Invariante X X X X X X X X X X 83% Normalizzatore X X 17% Posizioniere X X 17% Simulatore X X X X 33% Sopportatore X X X 25% Stampatore X X X X X X X X X X 83% Stralciatore X X X X X X X X X X X 92% Table 2 - Object utilization in Sinfonia products; rr= reuse rate
21
3.2 Standard working process architecture
To get an idea of how objects work and interact with each other to access a standard work process (these phases are present during all the Sinfonia suite products operations).
Figure 4 - Activities/objects interaction
22
4 Development
4.1 The Athena methodology
Athena's will to protect its brand and performance reflected in the development of control code which guarantees possible risk limitation.
In fact, developing product with an organized code allows:
To avoid malfunctions;
To rely on this aspect and to convince customers about the possibilities, even for its internal operators, to safely and independently configure product parameters without activating a new contractual relationship with Athena.
The development methodology designed by Athena is based on a programming meta-language, created by the technical director and it is characterized by a positional notation which eliminates the use of tags through txt files and finally to program both asp.net and SQL queries in a very simplified way.
The meta-language was developed in Visual Basic and can greatly simplify the software de-velopment process at the expense of a substantial rigidity in terms of different usable pat-terns. The meta-language utilization advantages are evident (Table 3): as it appears, writing three lines of code in the meta-language (left column) generates the code snippet in the asp page shown in the right column.
23
ATHENA META-LANGUAGE ASP.NET PAGE
Grid view creation:
eventi;g_risultati;inpa,corp;luce,g_risul-tati_sele
Grid view loading:
interrogazioni; g_risultati;select * from logbase where
(ti-pomsg='@dr_tipo_attivita')
Visualization:
eventi;g_risultati_sele; f_risultati_ca-mpi,a,0,g_risultati,o,0
<asp:GridView ID="g_risultati"
AllowSorting="true" runat="server" EmptyDataText="Nessun risultato ottenuto" OnSelectedIndexChanged="azio_button" AutoGenerateColumns="False" DataKeyNames="corp"> <Columns>
<asp:CommandField
HeaderStyle-HorizontalAlign="Center" ItemStyle-HorizontalAlign="Center" HeaderText="S" HeaderStyle-Font-Bold="true" ItemStyle-BorderWidth="2" ButtonType="Image" ItemStyle-Width="25" ItemStyle-Height="15" selectImageUrl="~/App_Themes/athena/im-ages/Execute.png" ShowselectButton="true" /> <asp:TemplateField> <HeaderTemplate>
<asp:Label ID="Label28" SkinID="gridview" Text="Caev" runat="server">
</asp:Label> </HeaderTemplate> <ItemTemplate>
<asp:TextBox ID="caev"
SkinID="gridview" runat="server"
Width="100" text= '<%#eval("caev")%>'> </asp:TextBox>
</ItemTemplate> </asp:TemplateField> <asp:TemplateField> <HeaderTemplate>
<asp:Label ID="Label30"
SkinID="gridview" Text="stato"
runat="server"> </asp:Label> </HeaderTemplate> <ItemTemplate>
<asp:TextBox ID="stato"
SkinID="gridview" runat="server"
Width="40" text= '<%#eval("stato")%>'> </asp:TextBox>
</ItemTemplate> </asp:TemplateField> </Columns>
</asp:GridView>
Table 3 - Comparison among Athena and Asp.Net to realize asp grid view
Each product realization chain is characterized by an information flow, transmitted between the three levels related to the technical direction and the steps are synthesized below:
1. The first step is the transmission by the technical director of information relating to general aspects of product specifications: required feature, tools and database struc-ture. Obviously, a communication channel implies the need for a naming convention (Figure 5 - Page asp.net sample and conventionFigure 5) of involved parties;
24 2. The second step consists of development and dissemination to developers, from the development responsible, of excel sheets (Figure 6) representing the target product has to be implemented;
3. The third step is to develop. The developers use meta-language and received spread-sheets to create ASP pages (Figure 9).
25
Figure 6 - XLS page sample from Cash
26
5 Sinfonia suite
As above anticipated, the Sinfonia suite is composed of twelve products divided into five dif-ferent categories:
Smart: Info and SSI.
Back: Tick, Gemma and Norma.
Control: Money, Cash, Quadra, Gest and Note. Representation: Join.
Trasformation: Trasla.
Below, ten products are described in general terms and later (Chapter 6 and 7) are described in more detail the products on which the management has initially focused attention and whose documentation were more specifically realized, Gemma and Info.
The ten remaining products are described in terms of:
General functioning; Directions for use; Functional characteristics.
All products technical characteristics are the same and can be expressed through the tech-nologies they used:
Microsoft Windows Operating System;
Database SQL Server to store and handle, monitoring and reporting the data collec-tion;
Asp.Net for web presentation; Visual Basic for code development.
27
5.1 SSI - Standard Settlement Instruction
The product realizes, for the back-office, the direct management of the "standard settlement instructions” (conditions applied to a financial security during the buying process) daily posted on settlement circuits on behalf of the company or its customers.
The user is who cares about the settlement of buying and selling activities on the market. The main advantages the user finds using SSI is the simplicity with which the conditions can be changed, the completeness of scenarios able to be managed and, finally, the adaptability to any type of contract and country settlement rules.
5.1.1
Directions for use
Each contract must be settle on settlement circuits must be enriched with standard instruc-tions which vary in relation to:
The financial security covered by the contract; Trading market;
Settlement circuit; Market rules; Counter-party.
The tool allows, once the rules are defined (in a user-friendly way), fully automatic and safe contracts enrichments. The application avoids mistakes and risks, making possible to daily send correct settlement messaging. Rules are easily editable and definable so that back-office staff is fully autonomous and not any intervention on application are requested.
28
5.2 Tick - Settlement activities reconciliation
The product allows to daily check differences between settlement pending operations arising from bank applications and what appears in the settlement circuits or, if used, in the global custody system.
User is who cares about trading activities settlement operations.
The main advantage is always having the sureness that securities buying and selling opera-tions – both in domestic and foreign circuits settled - match those known to the bank infor-mation system.
Therefore, the system allows to balance without any difficulty whatever is managed on the settlement circuits with all that is governed by the internal information system thus avoiding the risk of penalties or overdrawn.
5.2.1
Directions for use
The use is at every financial institution that has contracts to be settled on circuits.
The product can keep under control without any administrative effort the settlement world by always having idea of the overall situation.
29
5.3 Norma - Atypical events manager
The product allows, using a powerful calculation engine, to automate events that would oth-erwise be manually handled to manage atypical events, related to corporate actions world that could occur during the financial security lifecycle.
User is who manages, in the securities back-office function, the administrative event of secu-rities, such as, for example coupons, capital increases, splits, reverse splits, conversions, etc. User benefit is the elimination of manual activities can occur when business applications don‟t handle the specific case related to the corporate actions events.
5.3.1
Directions for use
The versatility of the instrument and its ability to adapt to less common cases make it diffi-cult to define the directions for use. Its operations always begins from information extracted from company archives; subsequentially, information are processing with defined calcula-tion rules; finally, the result obtained from applying the rules is proposed as defined by the user in term of modality and time.
For better understanding the potential of the instrument, an example is below offered: Business case: a capital increase to generate 3 new shares every 7 held:
With the tool:
o is called the extraction from the deposit archive of the security situation on the due date;
o is defined the algorithm to be applied to the extracted result (situation); o is defined the result to provides in deposit movements and the remains are
highlighted in tabular form, available to the back-office; o is started the processing and in real time the deriving result.
30
5.4 Money - Cash Accounts Security area
The "accounts liquidity" in securities business area keeps under monitoring, for each cur-rency, account balances held with correspondents and, using information provided by securi-ties cash-flow, is able to signalize any overdrawn able to occur at the day or in the future. The product works on predefined parameters able to be changed by the user in a dynamic form. Based on these parameters, you can:
define, for each currency, an account working as treasurer of that currency;
establish the range of which exceed makes the application launch the "alerts" (i.e. if a stock exceeds a certain amount or if the negative balance exceeds a threshold or even if there are "large" amounts to be accounted for);
determine the rules that automatically trigger the "liquidity rounds”.
User is the back-office accounts business activity that, according to the corporate treasurer, are responsible for monitoring the liquidity of the accounts held with correspondents.
The immediately perceptible advantages are: elimination of manual operations;
possibility to real-time monitoring of liquidity related to the concerned accounts; the possibility of automatically making “liquidity rounds" based on set work
pa-rameters.
In summary, advantages are manual elimination and all the related economic benefits com-ing from a better liquidity management.
5.4.1
Directions for use
The tool allows to have a perfect control of the accounts and to enable the treasurer to make the right coverage and liquidities management. Operating in both batch and online it allows checking the account liquidity several times a day. Chosen a treasurer account, the system processes accounts to obtain the balances reports. At the same time, it asks cash-flow the in-formation about incoming and outgoing transactions that must be verified on individual ac-counts. After receiving the information, the application determines the liquidity of each indi-vidual account. These findings are given both to the back office and the treasurer for any eventual intervention.
If activated, the " liquidity round” function is able to send the Swift messaging necessary to turn all the liquidity surplus in the treasurer account of a currency or rather, drawing from the account treasurer, to realize the covers on overdrawn accounts.
31
5.5 Cash - Securities area cash-flow
The product constantly monitors the incoming and outgoing flow of money that is moved from the securities world. In particular, it monitors the flow required and/or generated by se-curities that are administrated by both domestic and abroad custodian and resulting from trading activities regulation.
User is the responsible of the corporate treasury which, through the information generated by the system, can have a correct perception of money flows (per single currency) incoming and outgoing that may occur on a given day.
The advantages are replacing lengthy searches in simple inquiries leaded over the system which returns, in real time, accurate and updated results.
5.5.1
Directions for use
The tool is essential to perfectly control the treasury, to avoid overdrawn on the account held by the custodians and to anytime know the expected cash-flows.
The tool do not only allow to monitor but also to guarantee the operator to work in conven-ient time both on overdrawn and capital uses management.
With appropriate adjustments, it may also be a service the bank can offer to sophisticated clients, such as a financial institution who need to real-time know its own cash-flows.
The system is fully automatic and is based on information already present in the various ar-chives of the corporate information system. In particular it considers:
All the expected revenues from securities held by custodians per individual settle-ment date11 and regulation currency12. Revenues are for coupon payments, divi-dends, capital repayments etc.;
All the outgoings expected from ongoing operations per individual settlement date and regulation currency, such as regulations for capital increases;
All the expected incoming and outgoing for a certain date and currency involving all the transactions ready to be settled. To lead this activity is even considered the trans-action "state" and are calculated only those who have had the match while those that are waiting to be answered or who failed the matching session are excluded.
11 Settlement Date is a financial security term describing the date on which a trade settles. That is, the actual day on which transfer of cash or assets is completed.
32
5.6 Quadra - Accounting
The product is an application module that allows to "decouple" the business functional appli-cations from the accounting modules themselves. In particular, it avoids the management ap-plications to need to have within them the accounting logics.
User is the company information system responsible and in particular who deal with the ac-counting systems in terms of application management.
Benefits are tied to the ability to generate, in accounting, charts of accounts without need to interrogate the business functional modules and, so that, in far more restricted times.
5.6.1
Directions for use
Quadra is essential in the business environments in which the accounting is under the direct supervision of accounting services: in this case, the accounting service is the only entity that defines, in view of an event, their accounting development.
It is useful when the aim is to manage the accounting logic in business applications but being able to send accounting voices already defined to the accounting modules.
It is even useful when, for internal administrative or external prescriptive requirements, the accounting logic must be quickly changed without, therefore, going to affect different appli-cations.
33
5.7 Gest - Management Control development
The product is capable of create, in view of a happened business event, one or more custom protocols in order to feed applications delegated to the management control.
The product is placed downstream of business applications from which it receives the infor-mation.
The received data are then processed, enriched and packaged according to the needs of ap-plications responsible for management control.
User is the operator who handles corporate information system and especially those who have the responsibility, by terms of application, of management control.
User benefits are many and are mainly linked to the programming elimination to offer ser-vices such as interaction with management control, the enrichment of the information re-ceived and the forwarding to management control as it requires.
5.7.1
Directions for use
The product is modular structured and capable of solving complex cases. In particular, can be used as:
decoupling application: it avoids direct connection between business applications and those of management control;
input paths transformer: it leave unchanged both feeding applications and receiving ones;
information enrichener: it receives, by accessing to other applications, data such as, for example, the master data files, paths, etc.;
business information compressor: when, for example, the management control appli-cation is only interested on the product/service and not on the number of times it was used by a client.
34
5.8 Note – Services Billing development
The product generates, by drawing input coming from the business applications, one or more "basic service information" that becomes available to the application dedicated to rendered services billing.
“Basic information service" means a standard set of information used to the later billing cal-culation.
User is the operator who handles corporate information system and especially those who have the responsibility, by terms of application, of billing services.
User benefits are many and are mainly linked to the programming elimination to offer ser-vices such as interaction with billing systems, the enrichment of the information received and the forwarding as it requires. Moreover, it even applies the most complex algorithms drawing directly from the company conditioner13.
5.8.1
Directions for use
It is used in all the cases in which is necessary the billing of services rendered both within and outside the company. For the outside services the application shall be used to check the invoice billing.
The product receives inputs from one or more applications that manage billing business processes.
It even enriches the information received with other such as, for example, economic condi-tions, billing or other time periods. Finally it aggregates the received information, it develops the necessary calculations and provides inputs to the application used as bill or rather docu-mentation printer. It also able, if required, to give input to management control.
13
It represents a database in which are defined all the conditions that the application manager apply to the processed data.
35
5.9 Join – Reconciliation
The product allows to bring two or more electronic environments to reconciliation.
User is the back-office operator mainly but the users range contains the entire field of recon-ciliation (accounts, suspended book-keeping voices, etc.).
The advantages are, besides the elimination of manuality, even the possibility to keep under constant control situations that, without informatics tools help, tend to be checked only peri-odically.
The product is directly manageable and governable by the user who independently and with-out any programming intervention decides what he will bring to reconciliation after the defi-nition of the information going to be verified.
5.9.1
Directions for use
In financial securities area, the world of reconciliations is vast and reconciliations are obvi-ously very important. Reconciliations may refer both to domestics and abroad from bank worlds.
Among the classic reconciliations, leaded between the domestic and the abroad world, as-sume a particular importance the account and securities statements that must be daily per-formed.
Among the internal reconciliations an example are those related to the transient internal ac-counts with book-keeping voices composing them.
In addition, internal reconciliations may also refer to the reconciliation of two distinct and separate electronic files in a sporadic and not repetitive way.
36
5.10 Trasla - Syntactic Transformer
The syntactic transformer allows to integrate systems operating with different – in terms of quality of information, syntax and amount of data – service protocols.
The product can generate, starting by an input protocol, one or more output protocols with different syntax and, eventually, enriched contents.
User is the company application developer, to whom the syntactic transformer is an indis-pensable tool.
Benefits are substantial both for those who develops software both for final users which can, in this way, operate in complete autonomy.
The product allow to create and refine, day after day, an ordered information system which, obeying infrastructure standard rules, not only brings benefits to both maintenance and re-placement of applications but also allows to quickly and easily change the conversation rules among different applications.
To the administrative users, the product gives the way to face, automatically, changes to the application dialogue channels and especially in the receipt of telematics information from customers.
5.10.1
Directions for use
Its most important jobs are in: Interface to and from external service platforms; Supporting the migration of an information system;
Preliminary uploading to new applications included in the information system; Support the deferred dialogue between applications realized to interchange
37
6 Focus on Info and Gemma
In the following chapter are, more specifically than before, analyzed the remaining products, the Info and Gemma applications. The products are analyzed by considering:
Users;
Directions for use;
Functional characteristics; Functional description; Application architecture; Definition of the data.
6.1 Gemma – Corporate Actions messages from custodian manager
The management of Corporate Actions information, sent from the custodian to the banks that keep financial securities in custody, is an expensive task for back-office both due to the scale of each administrative event that have to be managed and for the complexity of the commu-nication protocol, the 564/566/568 Swift messaging.
Typically, in fact, financial firms use to keep their securities in custody on different custo-dian and must therefore interact with Swift messaging originated from different sources. 564/566/568 Swift messaging, however, are used not uniformly, leaving its users free to flexibly organize the information structure. So that, each custodian has its own transmission 'dialect' and who is the aim to organize in a structured way the receiving of these messages to increase the degree of automation and get the back-office free of manuality, often cope with difficulties.
Gemma is inserted between the application environment engaged to incoming Swift
mes-sages and the business applications where the information are needed: securities registry, coupon, capital raises, tender offer, initial public offering etc.
Gemma is therefore a kind of check point for the back-office who uses the data to:
automatically provide the information to the management applications; balance the positions placed at the custodian with the internal findings;
lead the elaborations and, finally, balance with the custodian the final results of events administrative settlement.
38
Gemma is able to:
transcode (Figure 1), per sending custodian, messages content and make them avail-able on a database according to the corporate standard configuravail-able data dictionary; provide consultation services to the database for the back office;
create drawings to be offered to the various information systems applications that manage corporate actions events.
Figure 8 - Transcoding page
6.1.1
Users
"Internal user": is the employee of securities back-office which monitors with Gemma in a simple and quick way all the administrative events are announced and /or communicated by the Italian and foreign custodians about the securities held by them.
More specifically, the back-office operator has information always available on an electronic archive which retains the sequence in which they were received.
The information made available by Gemma are accessible both to a knowledge use and to deal with the management applications.
“External user”: is the bank customer, both an institution and a private, that holds securities and let the bank administering them. He displays and receives in an electronic the same
in-39 formation as the back-office does or just a part of them. May, if appropriate, revise the same information on its own system.
6.1.2
Directions for use
It has to be inserted between the receiving environment of Swift messages 5xx series and the enterprise applications. Is a kind of check point for the back-office using the data to:
provide information to specialized applications of securities administration;
balance, while the event settlement is performing, the starting positions of the custo-dian with the findings coming from internal archives before giving the way to the in-ternal settlement;
balance calculation results of deriving sent by the custodian with those of internal applications that control the customers.
6.1.3
Functional characteristics
The product consists of two service modules: The Data Dictionary and configuration parameters manager; The manager of information received by the custodians.
The Data Dictionary and configuration parameters manager
A web services platform allows an external user to insert and sustaining the necessary pa-rameters to properly interface the messaging. In particular this means:
Describing in a data dictionary the processing of messages composing elementary data divided per Event/Custodian and containing:
o General specifications (type, etc.);
o Receipt specifications (format, validation rules, schedule etc.);
o Distribution specifications (applications to which distribute, triggering etc.). Describing in a configuration environment:
o Receiving activities (flows, characteristics etc.); o Distribution activities (flows, characteristics etc.).
40 The manager of information contained in the messages
Any information as defined in the Data Dictionary is treated by the information manager as basic unit of work to which are associated:
The owner (Custodian); A time of receipt; A related security;
An event associated with the security.
The operational activities performed by the manager are:
Information acquisition: batch scheduling activities that, after the parameters con-figuration, it receives, validate and acquires on a service database the information contained in the messages through the transcoding on the internal standard, as in the data dictionary;
Back-office interaction session for acquired data: the back office, as well as access the data, may intervene, insert, vary or integrate single data in order to make the mandatory data complete and the event itself able to be issued;
Information distribution: batch scheduling activities that, on the basis of the configu-ration and status of events, run an excerpt of the events and make them available in a standard format stream.
6.1.4
Functional Description
The activities can be summarized as follows:
1. Definition activity that makes the management of the parameters useful to organize the service;
2. Information acquisition that makes the management both of Swift messaging loading and of findings coming from internal settlements;
41 3. Back-office interactive session is carried out on the acquired data to undertake the interventions on the enriched information and the variation of acquired data to refine the content and the balancing of the settlement accounting findings;
4. Information distribution that provides to the clients information on the capital events.
6.1.4.1 Definition activity
Definitional activities include: Custodians census that is the definition of all the Swift message senders; Clients census that is the definition of all the Swift message recipients;
Treated administrative events census that represents all types of administrative events which Gemma realizes the information data management and balancing. The types of events are uniquely identified by the CAEV field of Swift messaging (4 al-phabetic string). All communications of received event are however underlined in a receiving log while the census types are then represented in the “Dati Informativi” database;
Treated data census consists in drawing of all types of data managed in the Dati
In-formativi database;
Definition of translation dictionaries consists of the customizable descriptions of all the managed data in the Dati Informativi database;
Census of 564/566/568 upload activities from custodians that defines how to load the messages because of the Swift message type and custodian sending it;
Census of “domestic securities settlement” upload activities that defines loading rules for settlement information relating to the securities from the corporate informa-tion system that will be sent to the balancing system;
Census of "domestic monetary settlement" upload activities that defines loading rules for settlement information relating to the monetary from the corporate informa-tion system that will be sent to the balancing system;
Census of information extraction activities that defines characteristics of the differ-ent extracts to be prepared for clidiffer-ents;
Report that defines the reports with which personally representing different types of event from the back office.
42
6.1.4.2 Information acquisition
It is the scheduling batch activity that in according to the configuration parameters receives, valid and acquires, on the Dati Informativi database, the information coming from the custo-dian on the one hand and from the corporate information system on the other hand. Loading is performed according to two criteria:
All Swift messages are however shown in the log;
Only those messages relating to the treated administrative events appear in the Dati
Informativi with a standard data format appropriately described by using the
vocabu-lary of translation.
The information to be loaded are distinguished by their origin and are:
Coming from the custodians:
o 564 Swift: message with coded fields that notifies information relating to an administrative event during his whole life cycle;
o 568 Swift: message with free format that notifies information in a descrip-tive way and that it is used to complete the 564 where the encoded informa-tion are not able to completely describe the event;
o 566 Swift: message that notifies that settlement information of an adminis-trative event (relating to both securities and currency).
Coming from the corporate information system:
o Securities settlement Information: evidence on the corporate system related to the administrative event settlement about a security level;
o Monetary settlement information: evidence on the corporate system related to the administrative event settlement about a monetary level.
After the loading of 566 messages information those are then processed by the balancing tool that intersects them with the information coming from the corporate system in order to verify the consistency of data relating to the settlements.
