Portman er et porteføljestyringssystem. Fremadrettet ønsker Portman, at deres kunder skal anvende deres såkaldte Web API, hvor kunderne kan læse/skrive data direkte på Portmans database. Med afsæt i to danske finansielle virksomheder, tager denne business case udgangspunkt i omlægningen til API’et med eksempler på hvornår API’et repræsenterer et fordelagtigt alternativ, som organisationen kan drage fordel af – og hvornår det ikke gør, baseret på det eksisterende system set-up.

Af Michael Gaihede, Manager | 21^st of November 2017

Portman til afkastberegninger

En stor dansk finansiel virksomhed har gennem en årrække brugt Portman porteføljestyringssystemet til at foretage afkastberegninger på en række porteføljer primært indeholdende værdipapirer.

Ved beregning af afkast for porteføljer hvor der indgår instrumenter i fremmed valuta, beregner Portman afkastet i lokal valuta ved at anvende periodens ultimo valutakurs. Da virksomheden imidlertid har månedlig regnskabsrapportering, opstår der regnskabsmæssige differencer, når afkastperioden er f.eks. 6 eller 12 måneder (fordi de månedlige valutakurser ikke stemmer med valutakursen efter 6 eller 12 mdr.).

Databaser

Af denne årsag etablerede man en selvstændig database, hvori man lagrede de månedlige afkast tillige med en række andre kundespecifikke data, til anvendelse ved øvrige beregninger og udarbejdelse af rapporter.

For at kunne tilgå og arbejde videre på data – både i Portman og i virksomhedens egen database – har virksomheden gennem en årrække udviklet et avanceret funktionsbibliotek i Excel (som VBA plug-in moduler).

Fra et Excel regneark kan man derfor gennemføre skræddersyede beregninger samt generere og indlæse data til efterfølgende rapportering.

Selvom et stort antal funktioner i Excel modulerne læser og returnerer data udelukkende fra Portmans tabeller (f.eks. beregning af den procentvise kursændring mellem to datoer på et givet aktiv), er der ofte tale om kombinationer af data fra hhv. Portmans og virksomhedens egen database (implemen­teret som såkaldte SQL joins) – bl.a. for at undgå dobbeltregistrering af stamdata i virksomhedens database.

Portman til håndtering af kundeinvesteringsporteføljer

En anden dansk finansiel virksomhed bruger også Portman, men til håndtering af et stort antal kundeinveste­rings­por­teføljer – herunder udarbejdelse af månedlige afkast-, beholdnings- og risikoopgørelser, som fremsendes per e-mail.

Virksomheden har desuden selv udviklet et system, som rekvirerer en lang række oplysninger fra Portman, og er i stand til at kombinere disse porteføljedata med oplysninger fra andre systemer for bl.a. at kunne give et mere fyldestgørende engagement overblik.

 

Analyse af alternative scenarier

Herudover, kan systemet anvendes til at foretage portefølje re-balancering- og omlægningssimulationer, hvorigennem alternative scenarier kan analyseres. Hvis en given re-balancering bliver lokaliseret og identificeret, kan systemet efterfølgende sørge for at afgive samlede allokeringsordrer til fondshandelssystemet og styring af de korrekte porteføljefordelinger.

Systemet er udviklet i C#/.NET og bruger – ligesom det første system – SQL til at rekvirere relevante data fra Portmans database.

LÆS MERE: Robotics Software

 

Portman Web API

Igennem længere tid har leverandøren af Portman – Vitec Aloc – foreslået sine kunder, at de fremadrettet skal anvende det såkaldte Portman Web API (Application Programming Interface) i stedet for at læse/skrive data direkte fra Portmans database ved brug af SQL.

Det er der som udgangspunkt god mening i, da brugen af et API tillader leverandøren at ændre i databasens tabelopsætninger, navne, objektmodel m.v. uden, at det får nogle konsekvenser for systemets brugere – herunder andre systemer som henter data fra Portman (i det omfang at kun API’et bruges).

API til indlæsning af data

Læser man derimod direkte fra Portmans tabeller, siger det sig selv, at data læsning vil fejle, hvis et tabel- eller feltnavn bliver ændret, hvis relationer mellem tabeller ændres, osv.

I den situation vil det blive nødvendigt at ændre i de pågældende SQL statements for at imødegå databaseændringer. Tilsvarende skal der efterfølgende gennemføres en række test scenarier for at verificere, at ændringer er korrekt implementerede.

Havde man derimod kun brugt API’et til indlæsning af data, ville denne situation ikke opstå, da det er leverandørens ansvar, at sikre at API’et til alle tider leverer korrekte data.

 

REST baseret interface

Portmans API er baseret på webteknologi og anvender et såkaldt REST interface, (som er en udbredt standard for tilgang til funktioner og data på eksterne servere) i modsætning til et ”normalt” eller gammeldags API, som oftest er et modul, der kører på en lokal maskine (enten server eller klient).

Et REST baseret interface/API bruger en webserver til at kommunikere med, anvender altid tekstbaserede data (i modsætning til binære værdier), og data skal i det hele taget gennem mange lag, når en klient kommunikerer med en server. Ulempen herved er følgelig, at performance falder mærkbart, i forhold til læsning direkte fra en database. Hvorvidt det er et problem eller ej, vil afhænge af en konkret vurdering.

Fordele ved systemet

Omvendt er fordelen, at systemet som nævnt bliver immunt overfor ændringer i selve databasen, (som oftest materialiserer sig ved nye versioner af systemet) samt at man i princippet kan tilgå eller rekvirere data fra en hvilken som helst REST baseret server på internettet.

Havde man f.eks. et datterselskab i udlandet – med en lokal Portman installation – kunne man få fat i data ligeså nemt, som hvis man indlæste fra sin lokale Portman server.

Endelig er REST interfacet så udbredt, at f.eks. Excel kan tilgå data uden egentlig programmering – dvs. det er nemt at lave ad-hoc analyser m.v. i Excel.

LÆS MERE: Implementation of new trading system

 

Analyse og implementering

Har man et system som rekvirerer data direkte fra Portmans database – og overvejer at skifte til Portmans API – vil det være nødvendigt først at gennemgå den eksisterende kodebase for at fastslå, dels hvor omfattende det vil være at omlægge koden til API brug, og dels at kvantificere og vurdere hvor stor en performancereduktion der vil blive tale om (og om det er et problem i en konkret situation) – for performance vil blive dårligere, når man går fra et direkte databasekald til et REST servicekald.

Det er svært på forhånd at konkludere noget uden at kende de underliggende teknologier, der konkret er anvendt.

LINQ teknologi

I de to eksempler indledningsvist beskrevet ville den første situation medføre, at kundens eksisterende Excel VBA plug-ins først blev omlagt til en nyere VB.NET version, og dernæst at de nye plug-ins blev modificerede, så der kunne foretages ”joins” af data mellem to inhomogene systemer (data læst fra virksomhedens egen database med data læst fra Portman’s API) ved hjælp af den såkaldte LINQ teknologi.

Da udviklingsaktiviteterne hermed ville være relativt tidskrævende, samt at man kørte mange omfattende selvudviklede rapporter i løbet af dagen, valgte kunden at bibeholde sin eksisterende løsning med direkte databaseadgang, og i stedet modificere indlejrede SQL statements hvis/når det blev relevant.

I den anden situation var udviklingen nemmere, idet der kun krævedes omlægning af eksisterende SQL lignende statements (baseret på LINQ) til nye LINQ statements, hvor data i stedet indlæses fra Portman API’ets REST interface. Da data typisk kun indlæses en gang om dagen, er performance ikke noget problem, hvorfor kunden valgte API løsningen for derigennem at fremtidssikre systemet.

LÆS MERE: Amortization of loan fees

Omlægning til Portman API

Har man et eksisterende Portman system, som er ”forbundet” til et eller flere eksterne systemer, kan det som sagt være en fordel at benytte API’et mod disse systemer for at undgå eller minimere problemer med ændret database layout og –struktur. Som det vil være eksisterende kunder (med eksterne systemer) bekendt, foretager Vitec Aloc løbende ændringer i den underliggende database, hvilket ofte indebærer, at der kræves tilretninger i de eksterne systemer.

Der kan være tale om mindre rettelser (f.eks. ændring af datatypen på et felt), men også om mere vidtgående ændringer, hvor f.eks. en tabel opdeles i flere nye selvstændige tabeller, et eller flere felter i en tabel flyttes til andre tabeller m.v. Håndtering af disse ændringer kan i nogle situationer være endog meget tidskrævende at rette, da sourcekoden i de eksterne systemer skal gennemgås, tilrettes og systemerne testes inden, den nye Portman version kan tages i brug.

Netop derfor repræsenterer API’et et fordelagtigt alternativ, idet omfang Vitec Aloc ikke ændrer i selve API strukturen. Dette sker dog ind i mellem, men er sædvanligvis væsentlig mindre tidskrævende at tilpasse sig end underliggende databaseændringer (i nogle tilfælde ved at der er tilføjet nyere versioner af API funktioner, men hvor eksisterende metoder bibeholdes).

 

Afslutningsvis skal det understreges at CMP er uafhængig af Vitec Aloc, men har adskillige medarbejdere, som har arbejdet og stor erfaring med Portman. Tilsvarende har vi hjulpet mange virksomheder med Portman systemet, såvel forretnings- som IT-mæssigt.

 

Michael Gaihede, Manager

Michael har mere end 25 års erfaring som forretnings- og IT konsulent med fokus på finansielle virksomheder.

Lige siden starten af sin karriere har Michael været en del af IT udvikling med både udarbejdelse og implementering af porteføljemodeller, samt teknisk IT implementering. Michael har arbejdet på et stort antal platforme, med anvendelse af en lang række databasesystemer.

Michael er den del af CMPs stærke team af IT konsulenter, som leverer værdi til organisationen, ved at tilbyde afgørende ekspertise på tværs af en række tekniske områder.

Læs mere om Michael og vores andre konsulenter her.