---

### 1. Conceptual System Architecture

To meet a latency target of **< 100ms**, your system must separate the **Synchronous Evaluation Path** (the transaction API) from the **Asynchronous Feature Aggregation Path** (sliding-window calculations).

#### Synchronous Scoring Path (Merchant Request $\rightarrow$ Response)

1. **Phoenix Endpoint:** Recieves the transaction payload containing values like `3DS Used`, `Amount`, `Acceptor ID`, and location identifiers.
2. **Feature Hydration:** The API process looks up the historical entity state (e.g., *Acceptor 1 day number of deposits* or *Merchant 30 days total EUR amount*) from the in-memory Feature Store via high-speed keys.
3. **ML Inference (`Nx.Serving`):** The combined feature vector is passed to the ML engine to evaluate fraud probability.
4. **Decision Engine:** The score is evaluated against merchant-defined thresholds, and a JSON payload containing the score and explainability context (e.g., `card_failed_auth_ratio_1hr > 0.85`) is returned.

#### Asynchronous Streaming Path (Event Processing)

1. **Broadway Pipeline:** Immediately after receiving the transaction, an asynchronous event is pushed to an ingestion queue (e.g., RabbitMQ, Kafka, or internal GenStage).
2. **Velocity Processing:** Workers update aggregate metrics across expanding **Update Horizons** (`1 day`, `1 week`, `30 days`) for various **Entity Targets** (`Acceptor`, `Merchant`, `Shopper IP`).
3. **Feature Store Update:** The updated sliding-window numbers are written directly back to the cache layer, keeping feature records fresh for the next transaction.

---

### 2. Elixir Ecosystem & Library Stack

Instead of heavily relying on a split Python/Java environment (such as Kafka + Spark), Elixir allows you to handle both streaming pipelines and machine learning inference directly inside the same native runtime using the **Nx (Numerical Elixir) Ecosystem**.

| Component / Layer | Recommended Elixir Library | Purpose & Role |
| --- | --- | --- |
| **API & Web Interface** | `Phoenix` & `Phoenix.LiveView` | Handles low-latency REST/gRPC endpoints for merchants and real-time operations dashboards for fraud investigators. |
| **High-Throughput Ingestion** | `Broadway` (with `BroadwayKafka` or `BroadwayRabbitmq`) | Consumes incoming transaction logs concurrently, managing backpressure automatically during traffic spikes. |
| **In-Memory Feature Store** | `Redix` or `Mnesia` | Interfaces with Redis or Elixir’s built-in distributed database for sub-millisecond lookups of entity metrics. |
| **Data Manipulation** | `Explorer` | A highly optimized dataframe library (powered by Polars) perfect for parsing historical CSVs and doing offline feature engineering. |
| **ML Models & Deep Learning** | `Axon` | Builds and compiles supervised models (like neural networks or autoencoders) natively in Elixir. |
| **Traditional ML & Math** | `Scholar` | Provides traditional machine learning algorithms such as Isolation Forests (excellent for unsupervised anomaly detection) and Linear/Logistic Regressions. |
| **Inference Optimization** | `Nx` combined with `EXLA` | Compiles your Elixir ML code into highly efficient machine code using Google’s XLA (Accelerated Linear Algebra), targeting CPUs or GPUs. |
| **Inference Concurrency** | `Nx.Serving` | Natively batches incoming concurrent transaction scoring requests into single tensor operations, scaling your throughput efficiently under heavy load. |

---

### 3. Open-Source Reference Implementations & Frameworks

If you prefer to examine existing open-source frameworks (written in other languages) to benchmark your architecture, study the following production-grade solutions:

* **Jube (Go / Java):** A fully open-source (AGPLv3) anti-money laundering (AML) and real-time fraud detection transaction monitoring engine. It balances machine learning anomaly detection with custom merchant rule thresholds, manages velocity aggregation counts, and features built-in compliance case management pipelines.
* **FraudGT / GatedGCN (Python):** An academic and industry-vetted open-source graph neural network (GNN) framework tailored specifically for deep financial fraud detection. It excels at linking transaction nodes (Card $\rightarrow$ IP $\rightarrow$ Merchant) to unmask professional fraud rings.
* **Feast / Hopsworks (Python/Go):** The gold standard for open-source feature stores. Even if you build your feature store using Elixir + Redis, reading the architectural specs of Feast will give you a clear pattern for managing the **Feature Store Dual-Write** paradox (ensuring offline training features perfectly align with online inference features).

---

### 4. Implementation Blueprint: Building Natively in Elixir

#### Step A: Calculating Sliding-Window Velocity with Broadway

Your system must calculate historical features such as the `Number of limit exceeded response codes` or `Total EUR amount of merchant deposits` within specified windows. You can manage this with Broadway pipelines updating your Redis feature store:

```elixir
defmodule RiskPlatform.TransactionConsumer do
  use Broadway

  def start_link(_opts) do
    Broadway.start_link(__MODULE__,
      name: __MODULE__,
      producer: [
        module: {BroadwayKafka.Producer, [
          hosts: [localhost: 9092],
          topic: "transactions",
          group_id: "risk_feature_aggregators"
        ]}
      ],
      processors: [
        default: [concurrency: 50]
      ]
    )
  end

  @impl true
  def handle_message(_processor, message, _context) do
    tx = Jason.decode!(message.data)
    
    # Example: Accumulating "Acceptor 1 day total EUR amount"
    # Increments the rolling sum in Redis with an atomic command
    redis_key = "features:acceptor:#{tx["acceptor_id"]}:1d:amount"
    Redix.command!(:redix_client, ["INCRBYFLOAT", redis_key, tx["amount_eur"]])
    
    message
  end
end

```

#### Step B: Live Machine Learning Inference inside Phoenix using `Nx.Serving`

To process your incoming transaction attributes—like evaluating whether `3DS Used` is true/false alongside your hydrated rolling aggregates—set up an `Nx.Serving` process inside your application's supervision tree. This handles model execution inside the BEAM without requiring an external Python subprocess bottleneck:

```elixir
# In your application.ex supervision tree:
children = [
  {Redix, name: :redix_client},
  RiskPlatform.TransactionConsumer,
  {Nx.Serving,
   name: RiskPlatform.FraudModelServing,
   serving: Axon.Serving.predict(model, trained_parameters),
   batch_size: 16,
   batch_timeout: 5} # Batches incoming scoring requests every 5ms
]
Supervisor.start_link(children, strategy: :one_for_one)

```

Inside your **Phoenix Controller**, handle the transaction synchronously by querying your feature cache and executing the model inference runner:

```elixir
defmodule RiskPlatformWeb.TransactionController do
  use RiskPlatformWeb, :controller

  def score(conn, %{"acceptor_id" => acceptor_id, "3ds_used" => tds_used} = payload) do
    # 1. Hydrate features from cache
    redis_key = "features:acceptor:#{acceptor_id}:1d:amount"
    amt_1d = Redix.command!(:redix_client, ["GET", redis_key]) || "0.0"
    
    # 2. Build the exact feature vector matching your training matrix
    feature_tensor = Nx.tensor([
      if(tds_used == "true", do: 1.0, else: 0.0),
      String.to_float(amt_1d)
    ])
    
    # 3. Synchronous, batch-optimized inference execution
    prediction = Nx.Serving.run(RiskPlatform.FraudModelServing, feature_tensor)
    fraud_probability = Nx.to_number(prediction[0])

    # 4. Return decision and explainability context
    render(conn, "score.json", %{
      score: fraud_probability * 100,
      action: if(fraud_probability > 0.85, do: "DECLINE", else: "APPROVE")
    })
  end
end

```

#### Step C: Managing the Asynchronous Label Ingestion Pipeline

Because fraud chargebacks and bank card-network notifications (`TC40`) arrive with a **30 to 90-day time lag**, your database architecture must store a persistent lookup of original transaction hashes. Implement an asynchronous background worker (using Elixir `Oban` or standard PostgreSQL tables) to match these delayed risk labels to historical feature inputs, allowing you to periodically retrain your `Axon` models with updated, unbiased data to prevent operational model drift.

---

This video walks through an end-to-end framework layout for building financial data stream processing and fraud inference systems from the ground up, highlighting tools like Kafka and structural model retraining practices.