good explanation though in terms of a bank transaction as a customer i'd prefer if the transaction was detected as a fraud rather than pushing through but hey, everything comes down to preference which is why we have a lot of software accomplishing the same thing in a different way :-)
Wade here. The thing is, it may not be as simple as detect fraud or don't detect fraud. It's a balance. Yes, you obviously want to detect fraud as accurately as possible. But your bank also needs to be able to give people money when they ask for it. Financial systems, payment processors, etc, have very strict limits on how long they can take. If running fraud detection exceeds those limits, all transactions will be rejected, whether they are fraudulent or not. If that happens, the fraud detection is going to be largely irrelevant because the bank won't have any customers left. Having said that, in a real system, they can definitely have layers of fraud detection. Do the fast stuff in real-time, and leave the slower stuff for an async process.
So basically, the system would allow at least one fraudulent transaction to go through per account before it can mark the account as compromised. That can be an expensive proposition for the bank if these fraudulent transactions are high $$ value. Thoughts?
@@ConfluentDevXTeam +1 - a pre-auth fraud check would make sense to have a synchronous response, it’s a decision primarily made on the single transaction, who the payer is, and at this stage in the payment lifecycle you have minimal data. Now you could certainly have some offline and near real time features ready to serve your decision system here, but the more you’re doing the more latency you have and a lot of times you need to make this assessment in 500ms or less. Most banks are also doing batch captures, be it once a day or multiple times a day, so a sync response on a payment capture wouldn’t really make sense.
Great video , enjoying this series When it comes to transaction approval , there is the transactional part ( no pun intended ) where the system has to decide within ~100 milliseconds if it goes through or not . Here we must pack a a rule-based solution inside the monolith . Then for higher-latency ML models , the micro service takes over . I haven't seen or implemented the async approach myself but it feels like the right system design to me
The problem with event-driven architecture is that business almost always wants things to be strongly consistent. In the example, transaction processing is not strongly consistent with fraud detection. I mean a transaction can be processed, but detected as fraud after several milliseconds. So a compensation mechanism needs to come into play and business people usually do not like this :)
Excellent as always. Thanks, Wade.
Thank you, very interesting explanation about using asynchronous events
good explanation though in terms of a bank transaction as a customer i'd prefer if the transaction was detected as a fraud rather than pushing through but hey, everything comes down to preference which is why we have a lot of software accomplishing the same thing in a different way :-)
Wade here. The thing is, it may not be as simple as detect fraud or don't detect fraud. It's a balance. Yes, you obviously want to detect fraud as accurately as possible. But your bank also needs to be able to give people money when they ask for it. Financial systems, payment processors, etc, have very strict limits on how long they can take. If running fraud detection exceeds those limits, all transactions will be rejected, whether they are fraudulent or not. If that happens, the fraud detection is going to be largely irrelevant because the bank won't have any customers left.
Having said that, in a real system, they can definitely have layers of fraud detection. Do the fast stuff in real-time, and leave the slower stuff for an async process.
@@WadeWaldron-Confluent alright. now i know a bit more about banking system
So basically, the system would allow at least one fraudulent transaction to go through per account before it can mark the account as compromised. That can be an expensive proposition for the bank if these fraudulent transactions are high $$ value. Thoughts?
@@ConfluentDevXTeam +1 - a pre-auth fraud check would make sense to have a synchronous response, it’s a decision primarily made on the single transaction, who the payer is, and at this stage in the payment lifecycle you have minimal data. Now you could certainly have some offline and near real time features ready to serve your decision system here, but the more you’re doing the more latency you have and a lot of times you need to make this assessment in 500ms or less. Most banks are also doing batch captures, be it once a day or multiple times a day, so a sync response on a payment capture wouldn’t really make sense.
Great video , enjoying this series
When it comes to transaction approval , there is the transactional part ( no pun intended ) where the system has to decide within ~100 milliseconds if it goes through or not . Here we must pack a a rule-based solution inside the monolith . Then for higher-latency ML models , the micro service takes over . I haven't seen or implemented the async approach myself but it feels like the right system design to me
The problem with event-driven architecture is that business almost always wants things to be strongly consistent. In the example, transaction processing is not strongly consistent with fraud detection. I mean a transaction can be processed, but detected as fraud after several milliseconds. So a compensation mechanism needs to come into play and business people usually do not like this :)
@@ConfluentDevXTeam Totally agree