WEBVTT

NOTE Sentence-level transcript of https://www.youtube.com/watch?v=o6U_2vd967Y

NOTE One cue per sentence. Cue ids are the line anchors on /transcripts/o6U_2vd967Y.html. A cue ends where the next begins, or 2 s after its last word.

s1
00:00:01.309 --> 00:00:03.309
[music]

s2
00:00:12.960 --> 00:00:15.240
Hello everyone.

s3
00:00:15.240 --> 00:00:16.680
Thanks for joining.

s4
00:00:16.680 --> 00:00:21.600
So, I think like finally we are at the last day of the conference.

s5
00:00:21.600 --> 00:00:25.720
Personally, I had a great experience, learned a lot of new things.

s6
00:00:25.720 --> 00:00:33.600
So, I believe by the end of the session you would have at least few tea takeaways that you could apply in your work projects.

s7
00:00:33.600 --> 00:00:35.600
So, what is it we are going to learn?

s8
00:00:35.600 --> 00:00:40.640
So, we are going to learn how to integrate AI agents in your existing system.

s9
00:00:40.640 --> 00:00:51.280
So, this system it could be an even so system or it could be an even driven system or it could be any architecture that your business has invested over last few years,

s10
00:00:51.280 --> 00:00:51.960
right?

s11
00:00:51.960 --> 00:00:59.200
Because I always believe that these AI agents are more not just for the chatbots or the coding assistance, right?

s12
00:00:59.200 --> 00:01:07.000
So, the real value that you could bring out of these AI agents is like when you start to apply these into your business workflows.

s13
00:01:07.000 --> 00:01:09.000
And that is what we are going to learn.

s14
00:01:09.000 --> 00:01:14.320
And the problem space that we are going to work on today is the real-time fraud detection.

s15
00:01:14.320 --> 00:01:15.800
So, let me start with an example.

s16
00:01:15.800 --> 00:01:17.960
So, this is my personal experience.

s17
00:01:17.960 --> 00:01:26.040
So, a exactly a month ago, I purchased uh like I decided to purchase this laptop that I'm using for the presentation.

s18
00:01:26.040 --> 00:01:30.320
So, it's it costed me around like $3,500.

s19
00:01:30.320 --> 00:01:33.080
So, I waited for a right moment.

s20
00:01:33.080 --> 00:01:38.040
So, I was seeing like whether I have a nice offers and there was one moment.

s21
00:01:38.040 --> 00:01:39.480
So, I decided to buy.

s22
00:01:39.480 --> 00:01:43.280
I provided my card details and then I clicked on buy button.

s23
00:01:43.280 --> 00:01:45.920
Then my transaction got declined.

s24
00:01:45.920 --> 00:01:50.800
So, I thought like it was a network issue and some information has been misplaced.

s25
00:01:50.800 --> 00:01:54.440
So, I tried the second attempt and it was failed again.

s26
00:01:54.440 --> 00:02:02.240
Before I I the third attempt, so I got a call from the customer service asking to verify like if I am doing that particular transaction.

s27
00:02:02.240 --> 00:02:06.479
And I was like, yes, I was trying to do this for the past few minutes.

s28
00:02:06.479 --> 00:02:09.920
And I asked them like, why did you block my transaction?

s29
00:02:09.920 --> 00:02:12.560
Do you know what the response was?

s30
00:02:12.560 --> 00:02:17.959
They didn't know because I wouldn't blame blame them because they didn't know like why it was blocked.

s31
00:02:17.959 --> 00:02:24.520
It was somewhere in the system, either the rule-based engine or the ML-based engine would have taken that decision.

s32
00:02:24.520 --> 00:02:36.560
So, it would have looked through my transaction history or it would have have an average threshold beyond which like if it goes like just block the transaction, that would be the static rule that it would have had.

s33
00:02:36.560 --> 00:02:39.640
Because of which my transaction got declined.

s34
00:02:39.640 --> 00:02:46.600
So, the those are the key areas, like those are the uncertain areas where we are trying to integrate the AI agents.

s35
00:02:46.600 --> 00:02:50.600
Now, you might be thinking like what a great idiot, right?

s36
00:02:50.600 --> 00:02:58.480
Because it is already an uncertain case like why do you want to introduce an AI agent because it is also a non-deterministic by nature, right?

s37
00:02:58.480 --> 00:03:08.800
But the key point here that we are all trying to miss is that earlier in the rule-based engine or the ML-based engine like we don't have enough context.

s38
00:03:08.800 --> 00:03:13.200
We don't have enough real-time data that gets passed on to the system.

s39
00:03:13.200 --> 00:03:19.800
And those are the real data like that we are trying to capture from different domain context that we have in our domain.

s40
00:03:19.800 --> 00:03:29.239
And we are going to see like how we could build that architecture so that the AI agent can make use of it and come up with a verdict.

s41
00:03:30.560 --> 00:03:35.640
So, the domain that we are going to talk about is the real-time fraud detection as I mentioned before.

s42
00:03:35.640 --> 00:03:39.519
So, we had this rule-based engine like uh 5 years before.

s43
00:03:39.519 --> 00:03:45.200
And this rule-based engine was perfectly fine like it was working perfectly fine for few of the cases.

s44
00:03:45.200 --> 00:04:03.400
And but but the problem with this rule-based engine is like the maintainability because the fraudsters are trying to get intruded into a system like by a lot of different ways and you just need to keep on updating these static rules day by day and it it it's going to be really difficult for you to manage.

s45
00:04:03.400 --> 00:04:10.640
And that's when like we started to tie up with a third-party provider like who helped us to develop this ML model.

s46
00:04:10.640 --> 00:04:27.560
So we we have this ML base approach like where we shared with them transaction history or different features with them like based on that they trained the ML model and we were able to get a risk code based on that which with which like we were

s47
00:04:27.560 --> 00:04:30.840
able to block or approve the transaction.

s48
00:04:30.840 --> 00:04:43.919
But the problem with either of these approaches like either like we we were able to handle most of the transaction because it would fall below a certain threshold then we would approve the transaction

s49
00:04:43.919 --> 00:04:49.160
and if it goes beyond a certain threshold we would be blocking those transaction.

s50
00:04:49.160 --> 00:04:59.400
But majority of the transaction like few of the transaction like goes under the gray zone area and this is the area where it is really uncertain for those systems to

s51
00:04:59.400 --> 00:05:07.280
really come to a conclusion whether it is an fraudulent transaction or a legitimate transaction.

s52
00:05:07.520 --> 00:05:24.400
So what we are trying to do is like we we had built a system where we had both these tier one system which has this rule based or the traditional ML model and then we also had a tier two system which is agentic AI approach like

s53
00:05:24.400 --> 00:05:35.680
most of the cases would be handled really well by these existing system we already had because our thought process is not to exclude the systems that we already had.

s54
00:05:35.680 --> 00:05:43.240
We we are just trying to handle few of the areas like that is the gray zone areas with the help of agentic AI processing.

s55
00:05:43.240 --> 00:05:47.560
So this is the approach like that we decided okay let's move on with this approach."

s56
00:05:47.560 --> 00:05:53.560
But then our architecture, our domain is really complicated.

s57
00:05:53.560 --> 00:05:58.040
So, this is our different bounded contexts that we have internally in our domain.

s58
00:05:58.040 --> 00:06:01.920
So, the transaction context holds all the details about your transactions.

s59
00:06:01.920 --> 00:06:04.520
Like, it knows about the merchants.

s60
00:06:04.520 --> 00:06:07.920
It knows about the amounts that that you transact.

s61
00:06:07.920 --> 00:06:12.600
And everything related to a transaction would be residing on this particular context.

s62
00:06:12.600 --> 00:06:20.840
And it doesn't have any information about the customer it is handling, or it doesn't have any information about the payments or the device details.

s63
00:06:20.840 --> 00:06:23.400
That is what the bounded context means, right?

s64
00:06:23.400 --> 00:06:34.720
Because if you are from the DDD background or software engineering, like you would know that these are different bounded contexts like with like you wouldn't share the data among themselves.

s65
00:06:34.720 --> 00:06:37.720
Like, you need to do an asynchronous way of communication.

s66
00:06:37.720 --> 00:06:45.640
And like all sort of things like that you would do in a microservice communication would necessarily be done here as well.

s67
00:06:45.640 --> 00:06:49.000
So, then we do have accounts context.

s68
00:06:49.000 --> 00:06:56.680
All the details about the accounts like the KYC complaining, whether the user is KYC compliant, or anything about the customer.

s69
00:06:56.680 --> 00:07:01.720
Like, if you want to know about the customer, this would be the right context that we need to reach out to.

s70
00:07:01.720 --> 00:07:03.360
And there is a device context.

s71
00:07:03.360 --> 00:07:11.480
Like, we had stored all the device fingerprints, browser fingerprints, the OS that they are using over these device contexts.

s72
00:07:11.480 --> 00:07:16.240
Like, that would be really helpful like for detecting these kinds of real-time frauds.

s73
00:07:16.240 --> 00:07:18.960
And finally, like we had payment context.

s74
00:07:18.960 --> 00:07:26.840
So, any sort of chargebacks or anything related to the payments will be residing on this particular context.

s75
00:07:26.840 --> 00:07:37.240
So, now the problem that we have with this kind of an architecture is like we we really we really don't have a way or means to share these data

s76
00:07:37.240 --> 00:07:40.360
across different bounded contexts, right?

s77
00:07:40.360 --> 00:07:44.200
So, that's where like we started to introduce an orchestrator layer.

s78
00:07:44.200 --> 00:07:51.160
So, earlier like we had this orchestrator layer, but now we also have an agentic AI inside this orchestrator.

s79
00:07:51.160 --> 00:07:56.280
So, what this orchestrator does is like similar to a saga orchestration.

s80
00:07:56.280 --> 00:08:05.400
So, all the communication would go through this layer and then it would be communicated to other services like who are interested in those events.

s81
00:08:05.400 --> 00:08:09.120
And that is how like we define this orchestration layer.

s82
00:08:09.120 --> 00:08:17.760
And we also have an asynchronous way of communicating with within other different contexts like through a message broker.

s83
00:08:17.760 --> 00:08:25.440
If I zoom in a little bit on the transaction context, you could see what what are the details that these transactions are holding.

s84
00:08:25.440 --> 00:08:35.159
So, essentially like what happens is like when you have particular domain, you will be having different events that are emitted from that system.

s85
00:08:35.159 --> 00:08:38.039
So, those are really called as domain events.

s86
00:08:38.039 --> 00:08:45.600
And within our transaction context like we do have transaction created domain event, which is the start of entire transaction.

s87
00:08:45.600 --> 00:08:47.800
And we do have lot of integration events.

s88
00:08:47.800 --> 00:08:54.400
So, these are the events that comes from other contexts like payment contexts, device contexts, or account contexts.

s89
00:08:54.400 --> 00:09:03.200
So, events like transaction rejected, payment approved, payment rejected would come from other systems to our transaction contexts.

s90
00:09:03.200 --> 00:09:07.720
And these entire informations are stored in our NoSQL database.

s91
00:09:07.720 --> 00:09:11.760
We are currently using Cosmos DB as our event store.

s92
00:09:11.760 --> 00:09:16.520
And we are following event sourcing as our methodology to store the events.

s93
00:09:16.520 --> 00:09:24.280
So, what happens is like whenever user initiate a command, so that goes into our event store as an event as a business fact.

s94
00:09:24.280 --> 00:09:30.680
So, we are not mutating the state, but instead like we are appending all the events as when it arrives.

s95
00:09:30.680 --> 00:09:47.040
And what it really helped us to do is like once it arrives into the event store, so we have a kind of a mechanism called CDC or in no sequel word this is called as a change feed with which like whenever there is a change or update happens over a table,

s96
00:09:47.040 --> 00:09:52.960
so you will be getting notified and those changes could be propagated into different read models.

s97
00:09:52.960 --> 00:10:01.800
So, because in in in a real scenario like you won't be able to rely entirely upon the event store for the query operation for the read operation.

s98
00:10:01.800 --> 00:10:08.920
What you would do is like internal like you will be having different read models which are optimized for the read operations.

s99
00:10:08.920 --> 00:10:12.320
So, what we really had is like we had multiple read models.

s100
00:10:12.320 --> 00:10:20.160
So, one for timelines, one for customer information, and one for the fraud in the indicators, the risk view.

s101
00:10:20.160 --> 00:10:25.680
So, these are the different read model later layers that we had within our transaction context.

s102
00:10:25.680 --> 00:10:36.240
And essentially like you can't you can't you can't say other teams to follow the same patterns because even sourcing is not the one that other teams are also following.

s103
00:10:36.240 --> 00:10:51.440
So, what we did is like we also had this asynchronous way of communication by emitting those events into the message broker and those those events in turn will be processed by a worker process and then it will be reaching out to our projection layer.

s104
00:10:51.440 --> 00:11:04.000
So, the idea is like we need to gather all the data from all these different contexts and to have or build a semantic layer or you could call it as a materialized view which you could further use

s105
00:11:04.000 --> 00:11:05.040
within your agent

s106
00:11:05.040 --> 00:11:07.040
careful.

s107
00:11:10.200 --> 00:11:22.600
So, this is how the high-level flow looks like like we have all these different contexts and you could either use a CDC mechanism or a message broker to propagate those events into your projection layer.

s108
00:11:22.600 --> 00:11:28.000
And essentially like you will be having this intermediate layer like which is a worker process.

s109
00:11:28.000 --> 00:11:34.040
You need to massage your message events and then process it and then store them in the materials view.

s110
00:11:34.040 --> 00:11:41.760
So, this this is the entire high-level picture of how you could gather those data and form a materials view.

s111
00:11:41.760 --> 00:11:43.120
Now, coming to the agents.

s112
00:11:43.120 --> 00:11:51.240
So, so, we all know like agents are comprised of these three main components, the language models, the tools, and the memories, right?

s113
00:11:51.240 --> 00:11:55.720
So, this language model it it is not necessary to be a large language model.

s114
00:11:55.720 --> 00:11:57.120
It could be a SLM.

s115
00:11:57.120 --> 00:11:58.800
It could be an open-source model.

s116
00:11:58.800 --> 00:12:07.080
And the tools are by which like you could interact with the external APIs or the meta methods that you define in inside your application layer.

s117
00:12:07.080 --> 00:12:09.600
And you also need to have a memory layer.

s118
00:12:09.600 --> 00:12:20.000
For this particular use case like we are using an inch um short memory because uh you you can't really um rely on the long-term memory because you need to

s119
00:12:20.000 --> 00:12:30.000
um adhere to the uh SLA that you uh provided to the customers because for for the transaction uh to be processed like it should be sub 500 milliseconds.

s120
00:12:30.000 --> 00:12:33.560
And you we are currently using in-memory for this.

s121
00:12:33.560 --> 00:12:46.800
And essentially like what happens is like whenever there is an query comes into our language model, so it has this reasoning capability, the thinking capability with which like it tries to decompose the task into multiple chunks.

s122
00:12:46.800 --> 00:12:57.360
And each of these tasks in turn will uh go into the language model, do certain certain processing with the help of the tools, and it will see like if the end goal is reached.

s123
00:12:57.360 --> 00:13:01.520
And if it is not reached like it will try to go on in this loop.

s124
00:13:01.520 --> 00:13:06.480
So, this is what essentially happens inside the uh agentic framework.

s125
00:13:06.560 --> 00:13:14.920
But you should really know like when to stop this loop uh because uh this this depends uh this this is this might be varying.

s126
00:13:14.920 --> 00:13:17.400
This might be differing for different use cases.

s127
00:13:17.400 --> 00:13:24.320
For for our use case like we do have a metrics with beyond which like if we go like we we could break out of this loop.

s128
00:13:24.320 --> 00:13:26.760
And this could be varying for different use cases.

s129
00:13:26.760 --> 00:13:30.880
So, you should be really careful on avoiding this infinite loop.

s130
00:13:30.880 --> 00:13:35.320
And now coming back to our uh existing architecture.

s131
00:13:35.320 --> 00:13:40.120
So, what we did is like earlier like we learned about the transaction aggregate.

s132
00:13:40.120 --> 00:13:52.760
So, now we are emitting some events that gets translated into an integration event, which gets passed on to the message broker, and then it it is handled under the orchestration layer.

s133
00:13:52.760 --> 00:13:56.320
So, under this orchestration layer like we have different sub orchestrator.

s134
00:13:56.320 --> 00:13:58.680
So, we segregated the tier one.

s135
00:13:58.680 --> 00:14:00.760
Earlier like we just had the tier one.

s136
00:14:00.760 --> 00:14:07.360
Now, we had the tier one layer, which is handling the um rule-based engine or the ML-based engine.

s137
00:14:07.360 --> 00:14:12.600
And we also had now the tier two layer, which is going to be agent AK processing.

s138
00:14:12.600 --> 00:14:16.840
So, for this agent AK processing like we used fan out pattern.

s139
00:14:16.840 --> 00:14:28.440
So, we kind of use multiple agents within this layer, and we are trying to use a fan out pattern like um once the uh event has been reached out to the uh tier two layer,

s140
00:14:28.440 --> 00:14:32.839
we will be fanning out this um event to two different agents.

s141
00:14:32.839 --> 00:14:37.960
One is the risk analyzer agent, the other one is the behavior analyzer agent.

s142
00:14:37.960 --> 00:14:47.120
And once these agents like come to a conclusion based on the different tools that it has, it will finally send the response to the verdict.

s143
00:14:47.120 --> 00:14:50.040
And this verdict could be a metric.

s144
00:14:50.040 --> 00:14:55.880
It could be just an if condition inside your application layer, or it could be an another region.

s145
00:14:55.880 --> 00:15:06.200
Because what we seen is like if we are using just the metrics, it is again going back to the same criteria like where we had this rule-based um mechanism.

s146
00:15:06.200 --> 00:15:10.680
Uh so, there are many false positive cases that we are that we faced.

s147
00:15:10.680 --> 00:15:20.640
So, so we we in turn like we are trying to use a third agent in this verdict layer, which analyzes both the agents' responses and come to a conclusion,

s148
00:15:20.640 --> 00:15:25.840
which is then going to be emitted as an event back to this message broker.

s149
00:15:25.840 --> 00:15:35.520
So, this is how our saga flow continues and it gets into the payment context and then the payments are approved and then it is going back to the transaction context.

s150
00:15:35.520 --> 00:15:40.800
This entire loop is being done within our orchestration layer.

s151
00:15:41.200 --> 00:15:45.840
And this This is what I was talking about two agents that we had in this tier two.

s152
00:15:45.840 --> 00:15:59.280
So, one is the risk analysis agent, like what are the tools that we have in this an agent is that like we do have this kind of uh storing the fraud histories inside the semantic layer that we earlier see

s153
00:15:59.280 --> 00:16:02.480
and we are currently having a tool for that.

s154
00:16:02.480 --> 00:16:07.640
Like um it will just get those details from these projections layer.

s155
00:16:07.640 --> 00:16:16.680
And we also have a device trust layer, like all the device information will get stored into this semantic layer and it will just get those chunks alone.

s156
00:16:16.680 --> 00:16:30.520
And we also had um a business rules trying to migrate some of the rules that we had in the rule base engine over this tools and these are really specific to our business use case, so we are trying to move those into this tools.

s157
00:16:30.520 --> 00:16:33.240
And we also have a be- behavior analysis tool.

s158
00:16:33.240 --> 00:16:39.920
So So, there like we are analyzing the transaction patterns with two different plugins that we have.

s159
00:16:39.920 --> 00:16:50.839
So, based on these two different agents, the responses like we get to a final consensus and then that will be published as an event, which will be captured by the message broker.

s160
00:16:50.839 --> 00:16:58.720
And this will be listened or uh this will be subscribed by all the different contexts, which are interested in those events.

s161
00:16:58.720 --> 00:17:04.439
Now, as as as we seen earlier, like how does these um agents gather contexts?

s162
00:17:04.439 --> 00:17:06.920
So, from the projection layer.

s163
00:17:06.920 --> 00:17:18.120
So, these orchestration is going to consume these uh datas from the projection layers and how it is going to do is by the help of tools that it already has.

s164
00:17:18.120 --> 00:17:36.480
So, the transaction context, it is going to denormalize some of the counts, averages, average amounts that we had, the recent transactions, all gets into this semantic layer, and the device context is going to send all the details about the device trust score, location histories,

s165
00:17:36.480 --> 00:17:43.160
and all other related information about the locations, IP addresses to this semantic layer.

s166
00:17:43.160 --> 00:17:54.120
And the account context is going to send the statuses of the accounts, the KYC status, account age, whether the customer has been with us for the past few years.

s167
00:17:54.120 --> 00:18:02.480
So, based on that, like it will try to validate the um uh the the customer based on those informations.

s168
00:18:02.480 --> 00:18:04.840
And there is also the payment context.

s169
00:18:04.840 --> 00:18:14.320
From this, like we get to know about the recent payments that we gathered over these contexts into the semantic layer.

s170
00:18:14.600 --> 00:18:26.640
And and as I as I said earlier, so these tools get uh access to these projection layer, and which in turn will be used by these agents to come to a conclusion.

s171
00:18:26.640 --> 00:18:30.120
And this is the high-level um architecture that we had.

s172
00:18:30.120 --> 00:18:32.960
So, it could be any even source that you could use.

s173
00:18:32.960 --> 00:18:38.200
And basically, like you could have a relational database or no SQL database.

s174
00:18:38.200 --> 00:18:46.040
In turn, like you you need to just create the semantic layer for you to provide enough context to these AI agents.

s175
00:18:46.040 --> 00:18:49.200
And we do have this agentic layer in the orchestration.

s176
00:18:49.200 --> 00:18:59.960
So, we have this verdict tool, and then the short-term memory, and based on that, like whatever the result that we get gets on passed to the saga orchestration layer.

s177
00:18:59.960 --> 00:19:03.400
So, we I I I have prepared a POC.

s178
00:19:03.400 --> 00:19:14.680
So, based on the synthetic data, so I will just show you like how this works in in in Let me run this one.

s179
00:19:18.240 --> 00:19:20.880
So, these are the different contexts that we have seen earlier.

s180
00:19:20.880 --> 00:19:24.640
So, the transaction context, accounts, and device context.

s181
00:19:24.640 --> 00:19:38.800
So, from these, like we will get into the projections layer, and we will be having a CDC mechanism with which, like you will be able to progress propagate those events back to your semantic layer, which will

s182
00:19:38.800 --> 00:19:42.640
get in turn used by these AI agents.

s183
00:19:44.200 --> 00:19:52.840
So, here you could see So, there are multiple simulation events that we are simulating into the our systems.

s184
00:19:52.840 --> 00:19:56.080
And you could see bunch of events are currently populating.

s185
00:19:56.080 --> 00:20:05.080
So, these um events are propagating through different layers, the transaction layer, accounts, and then payments context.

s186
00:20:05.080 --> 00:20:17.400
And finally, like we also have this uh AI agent layer, like which which is going to try with the tier one processing, uh the ML processing.

s187
00:20:24.120 --> 00:20:26.560
Let me see.

s188
00:20:34.440 --> 00:20:37.600
I think it is just a database which is in the serverless mode.

s189
00:20:37.600 --> 00:20:40.640
Um I think it is coming up slowly.

s190
00:20:40.640 --> 00:20:51.880
So, but but yeah, the idea is like you will be able to see like two different agents coming up with two different uh conclusions, and you will be having a third agent which will take the final decision.

s191
00:20:51.880 --> 00:20:56.400
Uh that will be in turn emitted as an event back to your message broker.

s192
00:20:56.400 --> 00:21:03.600
And this saga flow will be continuing as for uh like how you designed your business architecture.

s193
00:21:04.080 --> 00:21:07.680
And going back to my presentation.

s194
00:21:09.680 --> 00:21:10.680
Yeah, that's it.

s195
00:21:10.680 --> 00:21:16.240
If you have any questions, like you can reach out to me offline or you can reach out to me on LinkedIn.

s196
00:21:16.240 --> 00:21:18.440
Thank you.

s197
00:21:18.574 --> 00:21:20.574
[applause]

s198
00:21:34.294 --> 00:21:36.294
[music]