Jag älskar liknelser! De är extremt användbara för att förklara nya koncept innan de blir allmänt kända. Liksom Enterna i Sagan om Ringen anser jag inte att något är värt att göra om de inte är värda att få ta lång tid.

Vi har byggt ett riktigt operativsystem för finansiella aktiviteter, på samma sätt som Microsoft byggde ett operativsystem för datorn. Det tog oss tio år att bygga den här saken och under de kommande tio åren är vår plan att bli något för alla.

Windows tyglar kommunikationen med datorn och standardiserar hur du använder processorn, minne, lagring och mycket mer. Bricknode standardiserar hur du utför finansiella aktiviteter av alla slag. Att handla aktier för oss är som att lagra data i datorminne för Windows. Inledningsvis var Microsoft tvugna att skapa sina egna applikationer ovanpå sitt eget operativsystem, som office. Vi har skapat ”office” -liknande applikationer som Bricknode Broker, Bricknode Fund Manager, Bricknode Lending och många fler för att utföra specialiserade finansiella aktiviteter och vi har bara börjat!

Driver du ett nystartat FinTech-företag? Kontakta oss, på samma sätt som ett nytt mjukvarubolag inte skulle börja med att utveckla ett nytt operativsystem kan vi leverera det till dig och du behöver inte oroa dig för de komplexa detaljerna runt att kommunicera med processorn, du kan sätta igång direkt med att bygga affärslogik och kundupplevelse.

Är du ett industriföretag med 20 aktieägare där du ska hantera ett aktieägarlån med ränteberäkningar och månatliga utbetalningar? Vi har ”office” -programmet för dig!

Vi levererar programvaran på det sätt som vi tycker att köpare av finansiell programvara ska kunna erhålla programvara under 2000-talet. Allt levereras samma dag, inga hållhakar och helt komponerbara och skalbara. Du aktiverar de saker du behöver när du behöver det, precis som App Store, och du betalar bara för det du använder!

Att starta ett finansiellt tjänsteföretag eller hantera finansiella aktiviteter har aldrig varit enklare. Om du vill bygga dina egna applikationer för att hantera finansiella aktiviteter, gå med i vår marknadsplats och vi ger dig en gratis uppsättning av Bricknode Financial Systems direkt som utvecklare. Precis som med App Store kan du bygga och marknadsföra ditt eget företag ovanpå vårt.

Låt oss starta revolutionen operatingsystemfor.finance tillsammans!

För att förenkla metoden CreateInternalInstrumentTransferOrders  och minska risken för fel har vi tagit bort de två fälten AcquisitionPrice och AcquisitionPriceAccountCurrency. Vi beräknar nu istället dessa via deras respektive value-fält: AcquisitionValue och AcquisitionValueAccountCurrency.

Men oroa er inte, vi kommer inte göra detta till en så kallad ”breaking change” utan kommer istället fasa ut dessa fält i api-metoden i en nära framtid. Se bara till att kolla igenom er kod så att ni inte använder dessa fält i framtiden eftersom ingen funktionalitet är kopplad till dessa fält.

Eftersom dessa fält är starkt kopplade är det onödigt att sätta värden på båda dessa fält, istället beräknas anskaffningsvärdena enligt följande uttryck:

AcquisitionPrice = AcquisitionValue / Units

och

AcquisitionPriceAccountCurrency = AcquisitionValueAccountCurrency / Units

Vi låter även användaren avgöra om systemet ska sätta dessa värden enligt en standard eller om dessa värden ska sättas till ett värde som användaren anger. Om fälten AcquisitionValue och AcquisitionValueAccountCurrency anges med ett värde skilt från null kommer systemet att använda uttrycken ovan för att sätta deras respektive anskaffningsvärden. Om användaren däremot inte anger dessa fält kommer systemet att sätta dessa värden enligt följande standard:

Anskaffningsvärdena på transaktionerna kopplade till kontot där tillgången flyttas från kommer alltid att beräknas från den aktuella positionens anskaffningspris.

Anskaffningsvärdena på transaktionerna kopplade till kontot dit tillgången flyttas till kommer däremot bero på om ordern resulterar i en teknisk handel eller inte.

Om ordern resulterar i en teknisk handel kommer anskaffningsvärdena beräknas enligt tillgångens aktuella pris. En order som inte resulterar i en teknisk handel kommer använda anskaffningspriset på den aktuella positionen för att beräkna anskaffningsvärdena och kommer då få samma anskaffningsvärden som transaktionerna kopplade till kontot där tillgången flyttas från.

I och med release 2.23 av Bricknode Financial Systems lade vi just till ett nytt grundläggande fält för Legal Entities vilket kallas KycDate. KYC är förkortning av ”Know Your Customer” och om ni driver ett reglerat finansiellt institut är sannolikheten stor att ni lägger ned en del tid på detta ämne.

Varför är då ett enkelt fält som detta så fantastiskt? Låt mig visa ett par saker som detta möjliggör.

För att vara compliant med många regelverk krävs det oftast att slutkunden uppdaterar sin personliga information och svarar på ett antal frågor årligen. I det här exemplet byggde vi ett snyggt formulär för att hämta in KYC information för en av våra kunder som vi sedan lade in som en länk under Systeminställningar och aktiverade funktionen ”Validera kundkännedomsdata vid inloggning”.

Det som nu kommer att hända är att kunden, när de loggar in på kundportalen i Bricknode Broker och om KycDate är för gammalt, får upp KYC formuläret. I det formuläret kan vi exempelvis automatiskt kontrollera och uppdatera folkbokföringsadress från register som SPAR och validera telefonnummer. Vi kan också utföra kontroller mot sanktionslistor och register för politiskt exponerade personer tillsammans med mycket mer.

I det här fallet tog vi även kunden igenom en process där nya allmänna villkor godkändes samt uppdaterade riskprofilen och preferenser för månadsspar. Allt detta möjliggjordes genom denna nya funktion direkt inne i Bricknode Broker!

Det är viktigt att förstå kontostrukturen för Bricknode Broker vilken innehåller olika typer av kundkonton, konton för utställare av finansiella produkter, huskonton och lagerhållningskonton som håller ordning på alla dina tillgångar. Vi släppte just en ny kort video som förklarar detta.

Vi har just släppt en film om hur obligationer fungerar samt lite info om vår nya applikation Bond Manager som släpps inom kort för BFS.

Finansiella institutioner ska löpande rapportera till Finansinspektionen. Med ständigt nya direktiv från regulatoriska myndigheter i Sverige och EU kan detta ställa till med mycket förvirring. För att de bolag som regleras av Finansinspektionen ska kunna uppfylla rapporteringskraven är det en förutsättning att den myndighet som reglerar dem har bra dokumentation om vad som förväntas och hur rapporteringen rent praktiskt ska genomföras. Skatteverket har exempelvis föredömlig dokumentation med tekniska specifikationer och hur varje kontrolluppgift ska levereras och hur rapportfiler byggs upp.

I dagarna har vi arbetat tillsammans med vår partner och kund Kreditbörsen, som är ett Betalningsinstitut och som använder delar av Bricknodes plattform och dess partner Lendysofts system för att leverera en tjänst inom peer to peer lån.

Finansinspektionen har en sida med information om Periodisk rapportering men vi ansåg att den inte var helt enkel att förstå sig på varför vi har skapat den här artikeln som hjälp på traven.

Som Betalningsinstitut ska Kreditbörsen rapportera varje halvår där rapporten ska innehålla företagets betalningsvolymer samt bolagets kapitalbas eftersom det finns ett kapitalkrav på dessa bolag.

Hos Finansinspektionen klassificeras denna rapport som två olika rapporter där kapitalbasen ska rapporteras till European Banking Authority genom Finansinspektionen medan rapporten om betalningsvolymer rapporteras till Finansinspektionen direkt.

Rapport om betalningsvolymer

Den här rapporten skapas som sagt direkt till Finansinspektionen och här ska det inte användas någon webbsida för att ladda upp rapporten. Istället installeras ett program från Finansinspektionen som finns för nedladdning på följande sida http://www.fi.se/programvara och där den som är ansvarig på bolaget loggar in.

Väl inloggad kan användaren se vilka rapporter som finns tillgängliga och som ska slutföras. För varje rapport presenteras ett tydligt formulär med fält som ska fyllas i med information. Informationen som ska fyllas i hittar användarna av Lendysofts plattform enkelt under sektionen Admin och sedan Reports som bilden nedan visar.

Admin sektionen i Lendysoft

Admin sektionen i Lendysoft

Under sektionen för rapportering kan användaren välja för vilket tidsspann rapporten ska genereras och för det första halvåret av 2017 kan det se ut som bilden nedan med exempeldata visar.

Rapport för betalningsvolymer i Lendysoft

Rapport för betalningsvolymer i Lendysoft

Informationen från rapporten i Lendysoft förs helt enkelt in i programmet från Finansinspektionen och skickas in genom att klicka på den knappen i programmet.

Rapport om kapitalbas

Vid tidigare rapporteringstillfällen har även denna del rapporterats direkt till Finansinspektionen i samma formulär som ovan men nu ska istället en fil laddas upp till Finansinspektionens webb tjänst som är av typen XBLR. Det finns sparsamt med information hos Finansinspektionen om detta och bolaget som ska rapportera blir dirigerat till European Banking Authority’s (EBA) hemsida där informationen är mycket svår att förstå sig på. Många länkar fungerar inte längre och de filer som går att ladda ned ger heller ingen tydlig vägledning. Finansinspektionen har en exempelfil på sin hemsida vilken dock inte innehåller några detaljer om den data som ska skickas för kapitalbasen men om användaren har lite förståelse för att arbeta med XML-filer går det att förstå att användaren ska ange institutionens registreringsnummer och datum för rapporten i vissa XML-element.

Efter fortsatt research via Google hittade vi ett insticksprogram till Excel från Altova som faktiskt löser nästan hela problemet. Genom att installera insticksprogrammet finns det nu en ny meny i Excel som heter EBA.

Användaren öppnar nu denna meny och klickar på Insert New Report. Ett antal val presenteras och efter att ha prövat sig fram och tittat i Finansinspektionens exempelfil där det som schema referens står text enligt bilden nedan går det att komma fram till att det är COREP som ska väljas som första alternativ i Excel rapporten.

Bilden ovan är tagen från att ha öppnat exempelfilen med Notepad++ där användaren kan se highlighting av XML-koden, detta är ett program som fungerar som Notepad/Anteckningar men med lite mer verktyg för att underlätta för användaren.

Vyn i Altovas insticksprogram ser ut enligt nedan.

Genom att ”plussa upp” COREP alternativet visas två nya alternativ enligt nedan.

I exempelfilen från Finansinspektionen står det ju corep_ind.xsd vilket vi då förutsätter mappar mot COREP IND som rapport i Excel vilket fungerade.

När användaren sedan klickar på OK skapar insticksprogrammet upp massor av tabbar i Excel bladet, en för varje rapport sektion som kan finnas med i COREP IND. Dessa sektioner heter C 01.00, C 02.00 etc. och genom att studera sektionen i Finansinspektionens exempelfil som heter fIndicators går det att förstå att det bara är C 00.01 och C 01.00 som behöver skickas in.

I Excel bladet finns det nu en sektion till höger som heter Tables och där kan användaren avmarkera alla sektioner av rapporten som inte behövs och bara lämna C 01.00 och C 00.01 enligt bilden nedan.

Vi kan nu fylla i C 00.01 som ser ut enligt följande bild.

Genom att klicka i första cellen för Accounting framework får vi en drop down med två alternativ.

Eftersom det inte finns någon dokumentation att tillgå på något enkelt sätt är det naturligtvis omöjligt att förstå om det är x1 eller x2 som ska väljas då användaren genom lite research kan förstå att en av dem representerar GAAP och den andra IFRS som redovisningsprincip. Genom att titta i exempelfilen från Finansinspektionen går det att utröna att det är x2 som ska väljas då den koden finns med i filen.

För Reporting Level är det samma problematik men eftersom vi hittar x6 i exempelfilen förutsätter vi att den ska användas.

I sektionen till höger där det står EBA Filing Pane ska vi också ändra till följande data:

Vi har ändrat Reference Date till rapportens datum samt valuta, språk, Scheme samt där det står Identifier ska institutets registreringsnummer hos Finansinspektionen fyllas i.

Nu är det vidare till C 01.00 där informationen om kapitalbasen ska fyllas i. Denna sektion ser ut enligt följande bild.

De siffror som står till höger om texterna representerar fältens id-nummer hos EBA och vid uppladdningen av rapporten till Finansinspektionen kan användaren få tillbaka ett felmeddelande om summorna i fälten inte går ihop. Då kommer användaren endast att få koderna tillbaka som är fel och en spartansk uträkning som visar vilka fält som ska gå ihop.

För att förklara hur denna validering, uträkning, går till kan vi titta närmare på övre sektionen i rapporten.

Texterna är indenterade under sina respektive rubriker vilket betyder att den summa som står vid OWN FUNDS ska vara summan av alla de underrubriker som står vid första indenteringsnivån. Om användaren fyller i en summa för OWN CET1 instruments och sedan går vidare för att fylla i ett värde i underrubrikerna ska den summan vara lika med totalen för fälten 080+090+091 exempelvis.

När användaren har fyllt i sina värden kan den klicka på knappen Validate för att testa om värdena går ihop.

I exemplet nedan har användaren fyllt i rapporten där bolaget har ett eget kapital om 1 600 000 kr varav 1 500 000 kr består av inbetalt aktiekapital samt 100 000 kr från årets vinst.

Genom att klicka på Validate får användaren följande rapport.

Användaren får några Errors men dessa hör till rapport C 04.00 och är en bugg i insticksprogrammet eftersom användaren har tagit bort sektionen C 04.00 från rapporten. Om det står Error från C 01.00 är det något som måste undersökas. Användaren kan nu fortsätta genom att klicka på Export to XBRL och får följande fil.

reportfile

Om bolaget inte har behov av att ange några fler poster än i denna fil går det ju bra att använda Notepad++ och editera i filen för varje rapport och sedan ladda upp den till Finansinspektionen. Alternativt kan insticksprogrammet från Altova köpas för €399 vilket är en bra investering för att säkerställa framtida valideringar och att filerna håller sig till framtida uppgraderingar av XML-scheman.

Om bolaget inte själva vill arbeta med rapporten går det också bra att outsourca detta till konsulter som exempelvis Parseport .