What is actually happening with AI? A number changes. if "new number" then replace ... that already worked 50 years ago. $BLK has been running monthly since 2022 in the savings plan which I enter manually. The purchases now all have to be changed manually?
Nothing else at the bank. Savings plan not executed because the ISIN is different. Hello ?
Is that how it should be? That works better.
@Kundenservice
Nothing else at the bank. Savings plan not executed because the ISIN is different. Hello ?
Is that how it should be? That works better.
@Kundenservice
•
44
•
@finanzperpetuum That is why we have mentioned 2 variants of how to proceed. :)
Banking processes are still very manual, which is why errors are common during the changeover.
In addition, automated solutions are again unfavorable for linked portfolios, as you can sometimes see from the splits. We carry it out on the same day and the broker issues the shares a week later. Correction bookings occur again.
Banking processes are still very manual, which is why errors are common during the changeover.
In addition, automated solutions are again unfavorable for linked portfolios, as you can sometimes see from the splits. We carry it out on the same day and the broker issues the shares a week later. Correction bookings occur again.
••
@Kundenservice if portfolio not connected AND iSIN BLK then replace 😉
Definitely works, was just a small suggestion to improve the customer experience 🤓
Definitely works, was just a small suggestion to improve the customer experience 🤓
•
33
•2Mon
@Kundenservice Perhaps you should generally rethink and improve the whole process regarding correction bookings instead of always pointing out that there are or will be correction bookings. The correction postings are not a natural phenomenon, but have been developed by you.
What would be the problem with a split to check whether the position size at the broker has already changed in the ratio in which you entered the split in your system and to simply "keep your feet still" instead of reacting with correction entries?
There is so much potential for improvement in the whole area of "correction bookings", just as food for thought :)
What would be the problem with a split to check whether the position size at the broker has already changed in the ratio in which you entered the split in your system and to simply "keep your feet still" instead of reacting with correction entries?
There is so much potential for improvement in the whole area of "correction bookings", just as food for thought :)
••
@Cype
If we were to "keep our feet still", we would have to build a data day.
In other words, only call up updates later when splits are booked.
We don't always have the splits in the database immediately, so we would make correcting entries despite the logic of not updating splits.
Or the Open Banking generally updates itself every 72 hours at the most, which should usually be enough for posting splits and ISIN changes, but then there are complaints because we retrieve data so rarely. :)
The correction postings are subject to a simple logic that is also transmitted by finAPI and the like in Open Banking. (In other words, even if we install a delay, the data from finAPI and co. will still arrive).
10 shares with us -> FinAPI transmits 11 shares to the broker -> no transaction with the broker -> FinAPI says "Yes, then just make a purchase as a correction so that it fits".
We already have a logic regarding splits and the adjustment at the broker.
However, not every broker carries out the split on time, which makes such logic almost useless in the end because the data backlog gets longer and longer.
After all, what do we do if the broker does not carry out the split on time, but the user trades again immediately after the price adjustment? :)
Amazon took 4 days with Scalable back then. Tesla at Trade Republic 3 days. At ING, the NVIDIA split was completed on the same day.
If we were to "keep our feet still", we would have to build a data day.
In other words, only call up updates later when splits are booked.
We don't always have the splits in the database immediately, so we would make correcting entries despite the logic of not updating splits.
Or the Open Banking generally updates itself every 72 hours at the most, which should usually be enough for posting splits and ISIN changes, but then there are complaints because we retrieve data so rarely. :)
The correction postings are subject to a simple logic that is also transmitted by finAPI and the like in Open Banking. (In other words, even if we install a delay, the data from finAPI and co. will still arrive).
10 shares with us -> FinAPI transmits 11 shares to the broker -> no transaction with the broker -> FinAPI says "Yes, then just make a purchase as a correction so that it fits".
We already have a logic regarding splits and the adjustment at the broker.
However, not every broker carries out the split on time, which makes such logic almost useless in the end because the data backlog gets longer and longer.
After all, what do we do if the broker does not carry out the split on time, but the user trades again immediately after the price adjustment? :)
Amazon took 4 days with Scalable back then. Tesla at Trade Republic 3 days. At ING, the NVIDIA split was completed on the same day.
••
2Mon
@Kundenservice Yes, that's exactly what I meant by "keep your feet still".
It's not that you should stop (of course you shouldn't do anything, as I said, food for thought :)) data from the broker or the interface, but to handle it a little more intelligently.
I don't really think it's relevant whether a user acts immediately after the price adjustment or not, at least not as a whole.
You don't just have one user who syncs his securities account with the broker, but dozens, hundreds or thousands. So perhaps you should look away from the individual "securities account status" towards the "broker status".
(Is the broker already ready / has he booked the split? Yes/No).
You apparently do not receive this data via your interface, but you could derive it yourself from your database. (Example: Ratio 10:1 --> split carried out if the position in the ratio has shrunk by 10:1 for x% of the securities accounts after the reconciliation)
As long as this has not been carried out, "keep your feet still" and possibly give the user a note in the position "Unfortunately your broker has not yet carried out the split, please be patient", instead of producing scrap data and giving the user instructions on how to correct it.
I understand the actual situation and your explanation. But I think we agree that there is room for improvement and that it is not a technical impossibility. :)
It's not that you should stop (of course you shouldn't do anything, as I said, food for thought :)) data from the broker or the interface, but to handle it a little more intelligently.
I don't really think it's relevant whether a user acts immediately after the price adjustment or not, at least not as a whole.
You don't just have one user who syncs his securities account with the broker, but dozens, hundreds or thousands. So perhaps you should look away from the individual "securities account status" towards the "broker status".
(Is the broker already ready / has he booked the split? Yes/No).
You apparently do not receive this data via your interface, but you could derive it yourself from your database. (Example: Ratio 10:1 --> split carried out if the position in the ratio has shrunk by 10:1 for x% of the securities accounts after the reconciliation)
As long as this has not been carried out, "keep your feet still" and possibly give the user a note in the position "Unfortunately your broker has not yet carried out the split, please be patient", instead of producing scrap data and giving the user instructions on how to correct it.
I understand the actual situation and your explanation. But I think we agree that there is room for improvement and that it is not a technical impossibility. :)
••