In banking and payments, fraud is a real-time event. A card is tested, an account is drained, a mule moves funds, all in seconds. The data that would reveal it already exists, spread across core banking, payment rails, customer channels, and risk engines. The problem is timing. By the time a centralized pipeline has extracted, moved, cleaned, and queried the data, the money is gone and the decision is a post-mortem.
The challenge: deciding on a fast-moving stream
Catching fraud means acting on the live transaction stream, not a nightly extract. Most institutions cannot, because their analytics depend on fragmented data across systems and regions, latency from centralized ingestion and batch processing, quality loss from duplication and transformation chains, limited traceability of how a decision was reached, and rising regulatory demands for auditability and control. When a fraud signal arrives late, it has no operational value. When the pipeline that produces it is too complex to audit, it becomes a liability of its own.
Why centralized analytics fall short
Traditional architectures move data into a central platform before anything can be decided. In a fraud context that fails three ways. Latency: centralized ingestion cannot keep pace with high-frequency transaction streams. Risk: every copy of transaction and customer data widens the attack surface and complicates data residency and governance. Bottlenecks: business and risk teams wait on central data teams, and the decision cycle slows exactly when it needs to be instant. Frameworks like BCBS 239, DORA, and GDPR increasingly favor traceability, locality, and controlled processing over large-scale central aggregation.
The Lascaris approach: a swarm of agents on your stream
Lascaris is the operating system you run your agents on. On your transaction stream you deploy a team of agents: they sense each event as it happens, coordinate, decide against the fraud and risk policy you set, and act, holding or flagging the transaction in real time. The data never moves into a new platform. The agents run where the data already lives, inside your own network, on your own Kafka, with shared memory and a single audit trail underneath them. Every decision they make is written to an immutable log: the inputs they saw, the policy they applied, and the action they took. That record is the difference between a model that scores fraud and a fleet of agents you can defend to a regulator.
Use case: real-time fraud on the transaction stream
The scenario. A bank operates across regions and business units. Fraud and risk signals are generated continuously across transaction systems, payment platforms, and customer channels. Centralized analytics cannot process them fast enough, so by the time a case reaches an analyst, the loss has already occurred.
The agent solution. With Lascaris, the agents execute alongside the systems that produce the data. They evaluate each transaction in flight, hold or flag the suspicious ones, coordinate across accounts and channels, and escalate only what needs a human. Aggregation happens only where required, and only at the level required.
The result. Real-time decisions instead of next-day case review. Fewer copies of sensitive transaction and customer data. More reliable signals, with fewer transformation layers to introduce error. A defensible record for every action, ready for audit.
Every decision on the record
A fraud agent only earns production when the bank can prove what it did and why. Lascaris records each decision as an immutable event, so risk, compliance, and audit work from the same evidence. That is what makes the agent deployable under DORA, the EU AI Act, and internal model governance, not just performant in a demo.
Runs where your data lives
Lascaris connects to your existing Confluent, Redpanda, or Apache Kafka and your systems of record. If you do not have a Kafka stack yet, it ships with its own. It runs on-premise or air-gapped, and the reasoning never leaves your network. As referenced in the Scalytics white paper Data Strategies in the Wake of AI, keeping execution in place rather than copying data into a central lake has reduced storage and duplication by up to 35 percent for distributed financial workloads, while improving traceability.
Regulatory and industry alignment
BCBS 239, principles for risk data aggregation and reporting: accuracy, timeliness, and traceability. DORA, operational resilience for financial entities, including auditable automated decisions. EU AI Act, governance and record-keeping for higher-risk AI in financial services. GDPR, data minimization and processing locality. These frameworks favor architectures that reduce unnecessary data movement while preserving transparency and accountability.
Why this matters
Fraud detection is a timing problem and a trust problem at once. The institutions that act on the stream and can prove every action gain both operational resilience and a defensible compliance posture. Lascaris provides that foundation without destabilizing existing systems or your regulatory standing.
Related capabilities: kafSCALE for the Kafka-compatible event plane, Lascaris for the sovereign agent runtime and audit trail, and Scalytics Private AI for governed model execution.
References:
- Basel Committee on Banking Supervision, BCBS 239 (https://www.bis.org/bcbs/publ/d239.htm).
- Bank for International Settlements (https://www.bis.org).
- Financial Stability Board (https://www.fsb.org).
- European Central Bank (https://www.ecb.europa.eu).
- General Data Protection Regulation (https://gdpr.eu).
