The result is save to /etc/fail2ban/jail.d/fail2ban-shodan-internetdb.csv.

Why? I mean for which purposes is it saved there?
Rather the question is why this is necessary to the time of ban?

If you use the info by yourself somewhere in a UI (web-form etc) or protocol, why it is needed immediately if IP gets banned and not on demand if it gets listed in the UI or that protocol.

Why? I mean for which purposes is it saved there? Rather the question is why this is necessary to the time of ban?

If you use the info by yourself somewhere in a UI (web-form etc) or protocol, why it is needed immediately if IP gets banned and not on demand if it gets listed in the UI or that protocol.

First is the reason why it saves to /etc/fail2ban/jail.d is because this is where it stores IP lists that have been banned. I assume it is easy for users to find more banned IP info.

Second is necessary to the time of ban. I just simply think that when an IP is unbanned it will be removed from jail.d, so I don't think that IP info is necessary anymore.

My idea simply enriches IP details when it is being banned. I would be glad to have some suggestions from you.

Second is necessary to the time of ban.

Again, for which exactly? You did not explain what you (or a user of that info) would achieve with that. And why it is necessary to time of ban.
Why I was asking that? See #3407 (comment) for a similar thing (explaining possible issues by synchronous actions communicating with external sites).

My idea simply enriches IP details when it is being banned.

Well, and I don't understand yet exactly that point - or rather its possible uses (and why it is needed at the time of ban).

It's similar to providing GeoIP information about the banned IP. The information from InternetDB would tell the user whether the connection came from a compromised IP, VPN, etc. It can be helpful to identify behaviors in activity that are happening against a network to create potential firewall rules or simply get a better understanding of who's attacking.

I know that it could be helpful and what it would tell the user...
Again this does not explain why it is needed at time of ban (what I was asking all the time).
Also it does not answer the questions of synchronous processing (I provided in comment above).

One can basically accumulate all information the world knows about the IP (and therefore probably retards the ban process for every single IP for minutes or hours)... However the question "why?" still remains.
I mean the primary goal of fail2ban is to protect against evildoers, if your nice to have additional info bothers this primary goal (and it does) - something seems not quite correct and the question "why it's needed at that point" is more than legitimate.

Simplest "fix" for such action would be to force running of that command in the background asynchronously (& at end, disown, nohup etc).
For instance something like that:

nohup cmd "<ip>" > /dev/null 2>&1 &

Just it may also introduce further issues, e. g. generate heavy load if some flood suddenly causes many bans for many IPs at once, etc... So normally one would either create some worker (or pool of them) retrieving that after ban asynchronously or provide a function capturing that info on demand (to time the user really needs it, not to time of ban).

Ah I think I understand. Yes, it could definitely run in the background. It isn't necessary to run synchronously with the ban as the information isn't consumed during ban time. The purpose was just to have a file that can be looked at to fingerprint the types of IPs that were banned.