Insurance Innovators Counter Fraud, Apéro

Erstmal steigt man in Zürich nichtsahnend in den Flieger nach London-City und trifft da die eigene Ex-Chefin vom MGB — nicht schlecht, kurz geschwatzt, alles wie immer. Und ja, ich hab noch genügend Kontakte zu den Data-Science-Leuten und lade die auch immer regelmässig an meine eigenen Meetups ein. Das ist doch unternehmensunabhängig, uns interessieren immer nur die Daten.

Danach wollte ich eigentlich von LCY bis zur Tower Bridge laufen, aber weil ich doch noch Shortbread für den Nachwuchs kaufen sollte, hab ich die Zonenkarte für TfL gelöst und bin durch die Gegend gefahren. Ist ja wie das GA daheim, ähnliche Verkehrsdichte, nur alles lauter und dreckiger. Aber London scheint Fortschritte im Kampf gegen das Auto zu machen, es ist nicht mehr ganz so extrem nervig. Vielleicht wird es ja irgendwann doch noch angenehm hier. Nach dem Abklappern der drei grossen Retailer Tesco, Sainsbury’s und Marks&Spencer hatte ich ein Kilo Shortbread in verschiedensten Variationen beisammen. Das sollte bis kurz nach Ostern reichen.

Aber ich bin ja zur Konferenz hier: https://marketforcelive.com/insurance-innovators/events/counter-fraud/, also geht’s um Versicherungsbetrug, das ist ja auch genau mein Thema. Morgen darf ich dazu was erzählen, aber ich hab natürlich meine datengestützte Sichtweise. Wenn mir hier einer mit Machine Learning kommt, metzel ich den mit Argumenten nieder. Bei uns geht’s (noch) nicht und wenn’s gehen würde, hätte ich es schon gemacht. Gibt viel bessere Betrugserkenner, nämlich Menschen. Die muss man so gut wie möglich unterstützen und ihnen soviel wie möglich langweilige Arbeit abnehmen, das ist das, wofür ich mich einsetze. Dann können sie nämlich ihre Kernkompetenz einbringen und sich auf komische Verhaltensmuster von Kunden konzentrieren.

Der Klassiker, auf den ich immer wieder angesprochen werde, ist immer Machine Learning auf Schadenstexten, also auf der kurzen Beschreibung, die man im System vom Schadenmitarbeiter oder vom Kunden oder von wem auch immer erhält. Viel weiter als bis zur Erkennung, was das vielleicht für ein Schaden sein könnte, kommt man da maschinengestützt (mit Sicherheit!) nicht. Viele Landessprachen haben in diesem Fall auch mal Nachteile. Irgendjemand hat mich noch gefragt, ob man nicht gleich aus dem Anruf eines Kunden alles komplett automatisiert erkennen kann, das sei doch trivial. Klar. Wenn man nur Oxford-Englisch spricht oder eine andere Variante einer weltweit verbreiteten Sprache mit vielen Milliarden Beispieldatensätzen zum Trainieren. Wenn man aber vier Landessprachen hat plus zig verschiedene Dialekte, wo es eben keinen vernünftigen Korpus zum Trainieren von Spracherkennung gibt, fällt das einfach mal (vorerst noch) aus. Obwohl ich es mir noch lustig vorstelle, wenn man dann Dialekt transkribieren würde und es am Ende aussähe wie ein Buch von Pedro Lenz — “Liebi Mobiliar, di schöni Fanny het mis natel gschlisse” (klassischer Haftpflichtfall, erkennt man sofort, aber persönliche Beziehung vom Geschädigten zum Verursacher ist auch erkennbar).

Lustige Leute hab ich auch schon beim Pre-Conference-Event (in CH = ein Apéro) getroffen, nämlich zum Beispiel zufällig die, die unsere Scoring-Software herstellen. Nach einer regelgesteuerten Bewertung werden die Fälle manuell geprüft und das ist auch gut so, weil dann nämlich am Ende ein Mensch die Entscheidung trifft. Dauert länger, kostet eventuell mehr, aber ich find das prinzipiell sehr gut. Stichproben, Zufallstreffer, Bauchgefühlverdachtsmomente, alles drin. Genau wie bei der Sicherheitskontrolle am Flughafen (auch wenn die noch mehr “false positives” akzeptieren, wenn sie dafür auch wirklich keinen “true positive” verpassen). Und: ich schau zu, dass ich das Regelwerk dahinter verbessere, dass also mehr Betrüger gefunden werden und gleichzeitig weniger ehrliche Kunden “verdächtigt” werden. Ganz klassisches Vorgehen in der Branche, ist auch alles Allgemeinwissen mit teilweise sehr lustigen Fällen:  https://www.bernerzeitung.ch/die-frechsten-versicherungsbetrueger/story/27006987 oder auch hier im Kassensturz.

Hotel, naja, Hilton halt. Hochpreisig, kann eigentlich auch nicht mehr als mein Schlafzimmer daheim und hat keine so gute Aussicht. Immerhin ein Bällebad. Rückflug gleich morgen abend.

35C3, Tag 2+3

Am zweiten Tag ging’s weiter mit Inside the Fake Science Factories, wo es um Netzwerke von Konferenzen und Journals ging, die so tun, als ob sie wissenschaftlich wären, aber eigentlich nur auf finanzielle Beiträge aus sind. Artikel werden zum Schein geprüft und dann veröffentlicht in dubiosen Zeitschriften, Konferenzen werden mit seltsamen Teilnehmern gefüllt irgendwo auf der Welt, es gibt inflationär viele davon. Das Recherchenetzwerk war relativ gross, vorgestellt wurde es uns von zwei investigativen Journalisten vom NDR und einem von der SZ. Zeitungsabos und Gebührengelder sind eben manchmal doch sinnvoll angelegtes Geld. Zum Nachschauen hier: https://app.media.ccc.de/v/35c3-9744-inside_the_fake_science_factories

Danach folgte der relativ lange und unterhaltsame Jahresrückblick des CCC, von dem mir noch nicht alles bekannt war: https://app.media.ccc.de/v/35c3-9975-jahresruckblick_des_ccc_2018

Ein paar rechtliche und praktische gute Hinweise gab es bei Verhalten bei Hausdurchsuchungen, eine Situation, in die man nicht kommen möchte, auf die man aber besser vorbereitet sein sollte.

Leipzig Messegelände

Tag 3 begann mit einer guten Zusammenfassung über Empirie und wie man Studien erstellt und deren Statistik liest und korrekt macht. Das war mir zum Glück fast alles bekannt. https://app.media.ccc.de/v/35c3-9686-die_dreckige_empirie

Der beste Vortrag von Tag 3 war der über Die dreckige Seite des Mobilfunks, wo ein Telekommitarbeiter, der die letzten 25 Jahre im Mobilfunkbereich draussen mit den Antennen zu tun hat, viele interessante Sachen erzählt hat, über Störer, Frequenzspektren, die BNetzA und noch so einiges mehr. https://app.media.ccc.de/v/35c3-9407-die_verborgene_seite_des_mobilfunks

Watt und dBM

Es lohnt sich auch wirklich, verpasste Vorträge online nachzuschauen, die Medien-Seite des CCC ist sehr gut gemacht und die Vorträge sind sehr schön aufgezeichnet. Vor Ort zu sein ist trotzdem noch spannender als sich das zu Hause im Sessel anzuschauen. Das ist seit langem und bei weitem die sinnvollste “Konferenz”, auf der ich war.

35C3, Tag 1

Der 35C3 hat begonnen. Dank Kontakten auf Twitter bin ich auch noch reingekommen. Das Leipziger Messegelände ist ziemlich gross, aber bis auf ein bisschen zyklischen Stau bei den Fressbuden immer zwischen den Vorträgen hab ich noch keinen Dichtestress erlebt.

Die eigens für den Kongress gebaute Fahrplan-App mit allen Vorträgen und Events drin aktualisiert gefühlt alle 30 Minuten, funktioniert aber bestens.

Der Vortrag zu den Spacecraft Operations um 16:10 Uhr war sehr spassig, weil die zwar auch noch viele andere Sachen beachten müssen (Orbits, etc.), aber im Kern sind sie einfach sehr weit weg vom Satelliten, nachdem sie ihn ins All geschossen haben, und müssen dann mit den Daten leben, die von dort kommen. Sie können noch Aktionen auslösen, haben Wartezeiten zwischen Kommando und Daten, haben auch nicht immer Datenzugriff (Horizont) und haben ungefähr 20’000 Messparameter für die Telemetrie. Das ist quasi wie ein Solarauto, nur mit mehr Budget. Kreativ werden die Leute auch erst, wenn sie wirklich eingeschränkt werden, dann muss man für die Ferndiagnose der Solarpanels erstmal überlegen, wie man genau herausbekommt, was nun eigentlich das Problem ist. Hypothesen aufstellen (man weiss ja, wie der Satellit aussieht) und dann überlegen, wie man die aus zigtausend Kilometern Entfernung prüfen kann. Sowas ähnliches hatten wir 2016 mit den Solarpanels beim SER2 auch, als man in den Daten der Solartracker gesehen hat, dass mit einzelnen Strings des gesamten Panels etwas nicht stimmen kann. Aus den Messwerten konnte man das damals relativ gut eingrenzen, aber am Ende konnte auch jemand mit dem Lötkolben hingehen und nachlöten.

Richtig cool war dann um 17:30 Uhr der Vortrag zu wallet.fail, wo Hardware-Crypto-Wallets gehackt wurden. Das sind so kleine Geräte wie ein TAN-Generator, die intern Zahlungen verschlüsseln, auf denen man dann auch Zahlungen freigeben kann. Und natürlich, wenn man das gehackt hat, installiert man erstmal Snake drauf und kann dann auf seiner Wallet Snake spielen (Doom ging nicht, da zu wenig Tasten da sind). Auch die Fernauslesung oder der Einbau eines Funkschalters, den man aus der Ferne betätigen kann (um z.B. eine Zahlung zu autorisieren), waren sehr witzig.

19:10 Uhr kam ein Hack zur Venenerkennung, einem der letzten biometrischen Merkmale, die noch nicht gehackt wurden. Es war erstaunlich einfach, nachdem sie auch erstmal gezeigt hatten, was genau gemessen/vermessen wird. Ich kannte das im Prinzip von den Fingerabdrücken schon aus der Biometrie-Vorlesung 2002 und die Venen sind halt nur etwas schwieriger zu “sehen”, aber am Ende doch ganz einfach. IR-Filter der Kamera raus, die Hand mit IR anstrahlen und schon kriegt man schöne Muster. Das ganze kann man mit Toner ausdrucken, sie haben es dann in eine Handform mit Bienenwachs vergossen und fertig war die Hand-Attrappe, die das System überlistet hat.

“What the fax” war der abschliessende Vortrag von gestern — klar, wer benutzt heut noch Fax? Aber sie haben HP-All-in-One-Geräte auseinandergenommen und genügend Lücken gefunden, wie man über die normale Telefonleitung in das Gerät reinkommt und von da eben weiter in das normale Netzwerk. Es ging bis runter zu den Kompressionsalgorithmen, die in der Firmware von HP verwendet wurden (einer aus Commander Keen, einem Uralt-Spiel — Vermutung war, dass der Programmierer des Spiels bei HP gelandet ist, das kann ich mir sehr gut vorstellen, dass man Code mitnimmt).

Lohnt sich jedenfalls, die Konferenz 🙂 Mit zwei der Leute vom Bahnhofsfoto-Projekt, deren Daten ich ja mit produziere, hab ich mich auch schon getroffen und es scheint noch ein weiterer Liegevelofahrer da zu sein, wenn ich das auf Twitter richtig interpretiere.

GPS/Exif geht wieder

Hier hatte ich festgestellt, dass ja die GPS-Daten aus meinen Bildern nicht mehr angezeigt werden. Nach ziemlich langem Debugging bin ich drauf gekommen, dass es am PHP selbst liegen könnte, weil nämlich die Exif-Header gar nicht mehr korrekt ausgelesen wurden. Damit waren dann gar keine GPS-Daten zum Anzeigen da. Stackoverflow meinte was von einem Bug in PHP-Version 7.2 und ulkigerweise ist das natürlich die, auf die Hosteurope zuletzt alles umgestellt hat. Nachdem ich auf 7.1 zurückgestellt hatte, ging alles wieder. Dafür sucht man dann ewig nach dem Fehler und lernt eigentlich gar nichts Neues.

Datenaggregatoren bei Google

Dow Jones bei Google

Gestern war ich bei einem von Google gehosteten Event auf dem Hürlimann-Areal in Zürich. Der Hersteller von DNA (Data, News, Analytics) hatte zu drei Sessions eingeladen (nicht zu verwechseln mit der deutsch ausgesprochenen Wintersession im Bundeshaus). Was Dow Jones macht: Daten aus weltweit zugänglichen und verfügbaren News-Quellen sammeln, aggregieren, aufbereiten, und das in vielen Sprachen. Das läuft natürlich auf der Google Cloud Platform, sonst wäre ja jemand anderes der Host dieser Veranstaltung gewesen.
Continue reading “Datenaggregatoren bei Google”

SASOL2018, Nachmittagsszenario verbessert

Vorgestern hatte ich noch die Sonnenenergie relativ stark vereinfacht angenommen. Am späten Nachmittag würden bei der Fahrt etwa 250W an PV-Energie reinkommen, wohingegen man bei perfekt ausgerichteten Panels im Stand etwa 800W einnehmen können würde. Darauf hatte ich die letzte Berechnung ausgerichtet und war bei etwa ausgeglichener Energiebilanz auf eine erreichbare Strecke zwischen 62 und 70km gekommen (bei 50 respektive 90km/h). Hier nochmal die Grafik:

Optimierungskennfeld.

Die Neuberechnung mit tatsächlichem Sonnenstand ergibt: je nachdem, wie die tatsächlichen Messwerte der Panels von SER3 ausfallen, habe ich mich nicht massiv vertan bei der Schwankung der erreichbaren Strecke. Viel mehr kann ich realistischerweise nicht sagen als Dateningenieur 🙂 Die einzig tragbare Aussage dazu: bei der gleichen Geschwindigkeitsbandbreite (50-90km/h) schwankt die bei einer ausgeglichenen Energiebilanz erreichbare Strecke zwischen 74 und 80km, wenn ich die veränderliche Sonneneinstrahlung am Tagesrand mit einbeziehe. Typischerweise kämen jetzt zu der Aussage noch fünf Stufen Hierarchie und Management über mir, jedesmal würden die Powerpoints inhaltsleerer und buzzword-voller und am Ende käme heraus, dass wir nur 5Wh/km brauchen, keine Stickoxide ausstossen, das Adblue selbst trinken können und noch 42 Mio Fr. Gewinn damit machen 😀

SASOL2018, Energiebilanz von 15-17 Uhr abhängig von der Länge der Fahrdauer (Rest Ladezeit mit ausgerichteten Panels)

Allerdings würde es auch zu mir passen, dass ich mal wieder sehr konservativ rechne und lieber mit weniger eingenommener Energie plane. Die Messwerte werden es dann schon zeigen 😀

Vielleicht rechne ich noch ein Szenario über den gesamten Tag durch, aber das ist schon fast wieder Overengineering, weil am Ende eh erstmal die Hardware zuverlässig funktionieren muss, bevor meine letzten 3% Optimierung zum Tragen kommen.

Frühling statt Hochsommer

Südafrika hat ja doch ganz andere geografische Daten als Australien oder Nordamerika. Hm. Aber dieselbe Uhrzeit, das ist sehr praktisch, und auch keine Zeitzonen drin. Ich liebe Daten ohne künstliche Unstetigkeitsstellen 😀

In Nordamerika sahen die Einstrahlungskurven so aus (Leistung/Energie ohne Aufladen morgens/abends, Leistung/Energie mit Aufladen morgens/abends):

Die Tage gingen da etwa von 06:00 (Morgendämmerung) bis 20 Uhr (Dämmerung/Eindunkeln). Wenn ich mir dasselbe für Südafrika anschaue, sieht es anders aus:

Die Rennzeiten passen schon ziemlich gut zu den Sonnenzeiten, muss ich sagen. Start um 07:30 Uhr, da bleibt vorher eh nicht viel Zeit zum Laden. Je weiter wir nach Kapstadt kommen, desto länger können wir morgens im Prinzip schlafen 🙂 Der Rennstop um 17 Uhr jeden Tag passt auch recht gut mit der Dämmerung zusammen.

Zum direkten Ablesen der Energiemenge, ausreichend genau für unsere Zwecke, hier noch zwei diskretisierte Grafiken, aufgeteilt nach den vier grossen Orten der Strecke:

Relativ zu SER2 (bzw. zu irgendeinem Panel, es ist dieselbe Berechnung, nur Ort/Zeit verändert) sind es etwa 10-12% weniger Sonnenenergie als in Nordamerika bei der ASC2016. Da sich noch viele andere Parameter verändert haben, ist das aber nur ein grober Anhaltspunkt.

SASOL2018, Nachmittagsszenario

Das hier beschriebene Nachmittagsszenario musste ich doch mal genauer durchrechnen und darstellen. Dafür gibt’s ja R 🙂

Allerdings muss ich dazu einige Annahmen treffen, zum Beispiel die über den Verbrauch von SER3. Da hab ich mir mal eine Kurve zusammengebastelt, die ich dann entsprechend mit echten Messwerten von Langstreckenfahrten verbessern kann. Und nochmal der Hinweis: ein Tesla wiegt etwa zehn Mal so viel wie SER3 und verbraucht auch zehn Mal so viel.

Verbrauchskurve, hypothetisch

Jetzt kann ich mit den angenommenen Verbrauchswerten und der Annahme über die Sonneneinstrahlung folgendes Szenario durchrechnen:

  • 15-17 Uhr am Nachmittag (17 Uhr ist jeweils Schluss mit Fahren laut Reglement)
  • von diesen zwei Stunden wird eine gewisse Zeit gefahren, dann wird angehalten und geladen (=Panels senkrecht)
  • Beim Fahren: Verbrauch nach Kurve oben, konstante Geschwindigkeit, PV-Leistung 250W konstant
  • Beim Laden: Panels senkrecht, PV-Leistung 800W (s.u. *)

* siehe hier: Erkenntnisse WSC2013:

[…] von Sonnenaufgang bis 08 Uhr gibt’s im Maximum schon etwa 900 Watt (etwa 80-85% von dem, was unter maximaler Einstrahlung reinkommt) […]

Damit hab ich alles zusammen, um ein paar Kennlinien für verschiedene Geschwindigkeiten zusammenzustückeln, das kann dann so aussehen:

Optimierungskennfeld.

Jede Linie ist eine Geschwindigkeit, die Farbe zeigt die Energiebilanz, links sieht man, wieviel Kilometer man schafft abhängig von der Fahrzeit (Standzeit = 120min-Fahrzeit). Die schwarzen Punkte markieren die Energiebilanz-Null-Linie (+/-30Wh).

Ich hatte es fast schon erwartet, dass die gefahrene Geschwindigkeit gar keinen grossen Unterschied macht, wenn man am Ende dieses Szenarios die Energiebilanz anschaut. Und tatsächlich: zwischen 50 und 90km/h unterscheiden sich die erreichten Streckenlängen nur um acht Kilometer (62 statt 70km), man muss nur bei 50km/h 75min lang fahren und bei 90km/h hat man die Strecke nach 47min geschafft. Bei obigen Annahmen hat man also eine recht gute Variabilität.

Aber: die Abnahme der Sonneneinstrahlung ist noch nicht mit drin, das könnte durchaus noch deutliche Unterschiede ergeben; sowie natürlich echte Messwerte vom Fahrzeug. Wenn man eh zuviel Energie hat, könnte man für die letzten zwei Fahrstunden des Tages auch einen Energie-Zielwert vorgeben und dann an der Kurve ablesen, welche Geschwindigkeit man entsprechend fahren sollte.

Whiteboard-Strategieskizze SASOL2018

Also wenn ich im Sommer in Bern bin, hat ja die Nachmittagsstrategie zwischen Terminen eine grünblaue Nassposition recht weit vorn im Alphabet. Im Herbst/Winter kommen wieder Sessionen im Bundeshaus. Aber am Nachmittag bei der SASOL2018 kann es durchaus anders aussehen:

Drei Szenarien für einen bestimmten SASOL-Fahrfall.

Da ich noch keine echten Verbrauchs- und Leistungswerte von SER3 habe, orientiere ich mich an der ultimativen Statistik und den Erfahrungswerten von SER2.

Frage: kann es sich energetisch lohnen, anstatt zwei Stunden langsam dahinzukriechen, stattdessen eine Stunde lang anzuhalten und dann eine Stunde doppelt so schnell zu fahren? (man könnte das z.B. jetzt verallgemeinern in Wie hole ich die maximale Strecke bei fixer Energiemenge aus zwei Stunden Fahrzeit heraus? oder andersherum Mit welchem Tempo soll ich noch wie weit fahren und dann nachladen, wenn ich noch 0.5kWh netto reinholen möchte/muss?)

  • Uhrzeit 15-17 Uhr
  • Verbrauch: @60=15Wh/km, @30=10Wh/km
  • PV: 200Wh/h (vereinfacht, linearisierte Sonnenkurve, flache Panels beim Fahren), 1000W bei normalisierten Panels (gestopptes Fahrzeug)
  1. 2h mit 60km/h fahren: Strecke 120km, Energie -1.4kWh (1.8kWh out, 0.4kWh in)
  2. 2h mit 30km/h fahren: Strecke 60km, Energie -0.2kWh (0.6kWh out, 0.4kWh in)
  3. 1h laden, 1h mit 60 fahren: Strecke 60km, Energie +0.3kWh (0.9kWh out, 1+0.2kWh in)

Klare Antwort: ja. Wenn die Batterie eh voll ist und Platz braucht für den nächsten Morgen vorm Start, kann man bequem mit 60 zwei Stunden lang fahren. Wenn man aber eh knapp dran ist, gibt es ein Optimum, das nicht unbedingt darin besteht, langsam weiterzufahren, sondern auch (gefühlt* natürlich seltsam) so sein kann, dass man eine Stunde lädt und dann eine Stunde schneller weiterfährt. Man kann es ausrechnen, dass es nichts bringt, nur muss man noch nach der Einsicht handeln. Mal schauen, ob dieser Fall bei der SASOL eintritt und ob ich die Rennfahrer im Team überzeugt kriege — es sind auch diesmal wieder welche dabei, so langsam kenne ich diesen speziellen Menschenschlag. Eigentlich reicht es ja auch, wenn ich als Strategieberater den Teamchef überzeuge, die Hierarchie ist klar geregelt hier 🙂

*Das mag für Autofahrer genauso widersinnig erscheinen wie einfach mal hinter einem Velo herzufahren, anstatt sich mit illegaler massiver Unterschreitung des Seitenabstands vorbeizuquetschen, nur damit ich kurz danach eh am Stau gemütlich vorbeiliege, während sich die Dosen gegenseitig im Weg stehen.

Sonnige Vorbereitung für die SASOL-Telemetrie

Rechts im Bild: der MiniPC, der die Telemetrie-Daten von SER3 empfängt. Die Software ist inzwischen noch deutlich aufgebohrt; sieht so aus, als ob Roli mein Feedback und meine R-Skript-Auswertungen ganz gut mit eingebaut hätte. Das Begleitfahrzeug wird zum rollenden WiFi, der MiniPC hängt am Router-LAN, ich gehe mit meinem Laptop per WiFi via Router auf den MiniPC und hole mir dort die Daten live alle paar Sekunden ab.
Continue reading “Sonnige Vorbereitung für die SASOL-Telemetrie”