Was ist eigentlich mit KI ? Es ändert sich eine Nummer. if „neue Nummer“ then replace … das ging schon vor 50 Jahren. $BLK läuft seit 2022 monatlich im Sparplan welchen ich manuell erfasse. Die Käufe müssen jetzt alle per Hand geändert werden?
Bei der Bank Nix anderes. Sparplan nicht ausgeführt weil die ISIN eine andere ist. Hallo ?
Soll das alles so? Das geht doch besser.
@Kundenservice
Bei der Bank Nix anderes. Sparplan nicht ausgeführt weil die ISIN eine andere ist. Hallo ?
Soll das alles so? Das geht doch besser.
@Kundenservice
•
44
•
@finanzperpetuum Darum haben wir 2 Varianten genannt, wie man vorgehen kann. :)
Bankenprozesse sind noch immer sehr manuell, weshalb auch dort Fehler bei der Umstellung üblich sind.
Zudem sind automatisierte Lösungen wieder ungünstig bei verbundenen Portfolios, wie man manchmal an den Splits sehen kann. Wir führen ihn am gleichen Tag durch und der Broker erteilt die Anteile eine Woche später. Schon kommt es wieder zu Korrekturbuchungen.
Bankenprozesse sind noch immer sehr manuell, weshalb auch dort Fehler bei der Umstellung üblich sind.
Zudem sind automatisierte Lösungen wieder ungünstig bei verbundenen Portfolios, wie man manchmal an den Splits sehen kann. Wir führen ihn am gleichen Tag durch und der Broker erteilt die Anteile eine Woche später. Schon kommt es wieder zu Korrekturbuchungen.
••
@Kundenservice if portfolio nicht verbunden UND iSIN BLK then replace 😉
Geht bestimmt, war nur als kleine Anregung gedacht um die Customer Experience zu verbessern 🤓
Geht bestimmt, war nur als kleine Anregung gedacht um die Customer Experience zu verbessern 🤓
•
33
•1Mon.
@Kundenservice Vielleicht solltet Ihr generell mal den ganzen Prozess bezüglich der Korrekturbuchungen überdenken und verbessern, anstatt immer darauf hinzuweisen das es Korrekturbuchungen gibt bzw. geben wird. Die Korrekturbuchungen sind ja kein Naturphänomen, sondern genau so von euch entwickelt.
Wo wäre das Problem bei einem Split zu prüfen, ob sich die Positionsgröße beim Broker bereits im Ratio geändert habt, in der Ihr den Split in euerm System eingetragen habt und solange einfach "die Füße still zu halten" anstatt mit Korrekturbuchungen zu reagieren?
In dem ganzen Themenbereich "Korrekturbuchungen" gibt es so unendlich viel Verbesserungspotential, nur mal so als Gedankenanstoß :)
Wo wäre das Problem bei einem Split zu prüfen, ob sich die Positionsgröße beim Broker bereits im Ratio geändert habt, in der Ihr den Split in euerm System eingetragen habt und solange einfach "die Füße still zu halten" anstatt mit Korrekturbuchungen zu reagieren?
In dem ganzen Themenbereich "Korrekturbuchungen" gibt es so unendlich viel Verbesserungspotential, nur mal so als Gedankenanstoß :)
••
@Cype
Würden wir "die Füße still halten", müssten wir einen Datendelay bauen.
Sprich erst später Updates abrufen, wenn Splits gebucht sind.
Nicht immer haben wir die Splits sofort in der Datenbank, würden also trotz einer Logik keine Updates bei Splits zu machen, Korrekturbuchungen durchführen.
Oder das Open Banking aktualisiert sich generell maximal alle 72h, was in der Regel für die Buchungen von Splits und ISIN Wechsel reichen sollte, aber dann gibt es Beschwerden, weil wir so selten Daten abrufen. :)
Die Korrekturbuchungen unterliegen einer simplen Logik, die beim Open Banking auch von finAPI und Co in der Form übermittelt wird. (Sprich selbst wenn wir einen Delay einbauen, kommen die Sachen von finAPI und Co trotzdem.)
10 Aktien bei uns -> FinAPI übermittelt 11 Aktien beim Broker -> keine Transaktion beim Broker -> FinAPI sagt "Ja, dann mach halt einen Kauf als Korrektur, damit es passt"
Es gibt bei uns bereits eine Logik bezüglich Splits und der Anpassung beim Broker.
Nur führt eben auch nicht jeder Broker den Split pünktlich durch, was solche Logiken am Ende auch fast schon nutzlos macht, weil der Datenrückstau immer länger wird.
Denn was machen wir, wenn der Broker den Split nicht rechtzeitig durchführt, aber der Nutzer bereits direkt nach der Preisanpassung neu handelt? :)
Amazon hatte damals bei Scalable 4 Tage gebraucht. Tesla bei Trade Republic 3 Tage. Bei der ING war der NVIDIA Split tagesgültig erledigt.
Würden wir "die Füße still halten", müssten wir einen Datendelay bauen.
Sprich erst später Updates abrufen, wenn Splits gebucht sind.
Nicht immer haben wir die Splits sofort in der Datenbank, würden also trotz einer Logik keine Updates bei Splits zu machen, Korrekturbuchungen durchführen.
Oder das Open Banking aktualisiert sich generell maximal alle 72h, was in der Regel für die Buchungen von Splits und ISIN Wechsel reichen sollte, aber dann gibt es Beschwerden, weil wir so selten Daten abrufen. :)
Die Korrekturbuchungen unterliegen einer simplen Logik, die beim Open Banking auch von finAPI und Co in der Form übermittelt wird. (Sprich selbst wenn wir einen Delay einbauen, kommen die Sachen von finAPI und Co trotzdem.)
10 Aktien bei uns -> FinAPI übermittelt 11 Aktien beim Broker -> keine Transaktion beim Broker -> FinAPI sagt "Ja, dann mach halt einen Kauf als Korrektur, damit es passt"
Es gibt bei uns bereits eine Logik bezüglich Splits und der Anpassung beim Broker.
Nur führt eben auch nicht jeder Broker den Split pünktlich durch, was solche Logiken am Ende auch fast schon nutzlos macht, weil der Datenrückstau immer länger wird.
Denn was machen wir, wenn der Broker den Split nicht rechtzeitig durchführt, aber der Nutzer bereits direkt nach der Preisanpassung neu handelt? :)
Amazon hatte damals bei Scalable 4 Tage gebraucht. Tesla bei Trade Republic 3 Tage. Bei der ING war der NVIDIA Split tagesgültig erledigt.
••
1Mon.
@Kundenservice Ja, genau diesen Datendelay meinte ich mit "Füße still halten".
Es geht ja nicht darum, dass ihr aufhören sollt (Ihr sollt natürlich gar nix, wie gesagt Denkanstoß :)) Daten vom Broker bzw. der Schnittstelle abzurufen, sondern damit etwas intelligenter umzugehen.
Ob ein User direkt nach der Preisanpassung handelt oder nicht, halte ich jetzt nicht wirklich für relevant zumindest nicht in der Gesamtheit.
Ihr habt ja nicht nur einen User der sein Depot beim Broker synct, sondern Dutzende, Hunderte oder Tausende. Demnach den Blick vielleicht eher weg vom einzelnen "Depotstatus" hin zum "Brokerstatus".
(Ist der Broker schon soweit / hat er den Split gebucht? Ja/Nein).
Diese Daten bekommt Ihr anscheinend nicht über eure Schnittstelle, könntet Ihr über euren Datenbestand aber selber ableiten. (Beispiel: Ratio 10:1 --> Split durchgeführt wenn bei x% der Depots nach dem Abgleich die Position in der Ratio 10:1 geschrumpft ist)
Solange der nicht durchgeführt ist, "Füße still halten" und dem User eventuell einen Hinweise in der Posi geben "Dein Broker hat den Split leider noch nicht durchgeführt, bitte hab noch ein wenig Geduld", anstatt Datenschrott zu produzieren und dem User eine Anleitung zu geben wie er diesen wieder korrigieren kann.
Ich verstehe die IST-Situation und eure Erklärung. Ich glaube wir sind uns aber einig, dass es da Verbesserungspotential gibt und das es sich dabei nicht um eine technische Unmöglichkeit handelt. :)
Es geht ja nicht darum, dass ihr aufhören sollt (Ihr sollt natürlich gar nix, wie gesagt Denkanstoß :)) Daten vom Broker bzw. der Schnittstelle abzurufen, sondern damit etwas intelligenter umzugehen.
Ob ein User direkt nach der Preisanpassung handelt oder nicht, halte ich jetzt nicht wirklich für relevant zumindest nicht in der Gesamtheit.
Ihr habt ja nicht nur einen User der sein Depot beim Broker synct, sondern Dutzende, Hunderte oder Tausende. Demnach den Blick vielleicht eher weg vom einzelnen "Depotstatus" hin zum "Brokerstatus".
(Ist der Broker schon soweit / hat er den Split gebucht? Ja/Nein).
Diese Daten bekommt Ihr anscheinend nicht über eure Schnittstelle, könntet Ihr über euren Datenbestand aber selber ableiten. (Beispiel: Ratio 10:1 --> Split durchgeführt wenn bei x% der Depots nach dem Abgleich die Position in der Ratio 10:1 geschrumpft ist)
Solange der nicht durchgeführt ist, "Füße still halten" und dem User eventuell einen Hinweise in der Posi geben "Dein Broker hat den Split leider noch nicht durchgeführt, bitte hab noch ein wenig Geduld", anstatt Datenschrott zu produzieren und dem User eine Anleitung zu geben wie er diesen wieder korrigieren kann.
Ich verstehe die IST-Situation und eure Erklärung. Ich glaube wir sind uns aber einig, dass es da Verbesserungspotential gibt und das es sich dabei nicht um eine technische Unmöglichkeit handelt. :)
••