← Investor Overview
VajraCloudAI logo VajraCloudAI PoC Overview
Bank Data Ingestion: How It Works
VajraCloudAI KYC/AML Platform · Technical Overview for Bank IT Teams
Audience: Bank IT Head / Compliance Officer Version: PoC Stage Classification: Confidential

This document explains in plain terms how customer data moves from your bank's existing systems into the VajraCloudAI KYC/AML platform: for both new customers being onboarded and existing customers whose records and transactions are already in your core banking system. No customer data leaves Nepal at any point in this process.

System Overview Diagram

End-to-End Data Flow: New & Existing Customers
BANK SYSTEMS VAJRAAI PLATFORM EXTERNAL VERIFICATION 🏦 Branch / Mobile App New customer submits documents 🗄️ Core Banking System Customer records & accounts (Pumori / Finacle / Flexcube) 📊 Transaction Database Daily / real-time transaction feed 30-day rolling history per account 👤 Compliance Officer Reviews AI recommendations 🔐 Secure API Gateway TLS 1.3 · Mutual auth · Rate limiting 🪪 KYC Engine Identity verification · Risk scoring NRB CDD compliance check 📊 AML Monitor Transaction pattern analysis NRB 2025 STR typology matching ⚡ VajraCore GPU orchestration · Model serving 📋 Compliance Dashboard Risk scores · Recommendations · STR drafts 🏛️ DONIDCR National ID verification API 🔍 Sanctions Lists UN · OFAC · EU · FIU-Nepal (local copy, refreshed daily) 📤 FIU-Nepal / goAML STR submission (outbound) 🇳🇵 Data Stays in Nepal All processing on bare metal inside Nepali colocation HTTPS API REST API Batch/stream Results ID verify PEP/sanctions STR filing LEGEND Real-time API call External verification (dashed)

The Two Ingestion Flows Explained

🆕 New Customer Onboarding
1
Customer submits at branch or appTeller or mobile app collects: full name, DOB, document type, document number, address, occupation, income declaration, account purpose.
2
Bank system calls our APIYour CBS or onboarding app sends a structured JSON payload to our Secure API Gateway over HTTPS. One API call per new customer record.
3
KYC Engine processes the recordAI verifies document consistency, checks for red flags in stated income vs. occupation, and calls DONIDCR to verify the National ID number against the government register.
4
Sanctions & PEP screeningThe customer's name and profile is matched against our daily-refreshed local copy of UN, OFAC, EU, and FIU-Nepal lists. No live call to external servers per transaction.
5
Risk score returned in <10 secondsAPI returns: risk level (Low/Medium/High), recommendation (Approve/Review/Escalate), and reasoning. Compliance officer sees this in the dashboard or it's pushed back to your CBS.
🔄 Existing Customer Monitoring
1
Initial data migration (one-time)Your IT team exports existing customer records from CBS in a standard format (CSV or JSON). We ingest this once to build the baseline customer profile database. Typically done over a weekend.
2
Daily transaction batch feedEach night, your CBS exports the previous day's transactions as a file (CSV/JSON) via secure SFTP, or streams them in real time via API. Our AML Monitor ingests and analyses each transaction against the customer's risk profile.
3
Pattern analysis runs overnightThe AML Monitor applies NRB 2025 STR/SAR typologies across the full 30-day rolling window: structuring detection, cash volume anomalies, rapid fund movement, round-figure patterns.
4
Flagged accounts surfaced by morningBy the time your compliance team arrives, the dashboard shows any accounts that triggered alerts overnight, ranked by risk level, with the specific transactions that caused the flag.
5
STR draft ready if warrantedFor accounts requiring an STR filing, the system pre-populates the goAML report template with the relevant transaction data. Compliance officer reviews, edits if needed, and submits to FIU-Nepal.

What Data We Need From Your Systems

Data Field Source System Flow Method Required / Optional
Customer full name CBS / Onboarding system Both API Required
Date of birth CBS / Onboarding system Both API Required
Document type & number CBS / Onboarding system Both API Required
Permanent address CBS Both API Required
Occupation & employer CBS / Onboarding system Both API Required
Stated annual income CBS / Onboarding system Both API Required
Account type & purpose CBS Both API Required
Transaction date & amount Transaction DB / CBS Existing Batch Stream Required
Transaction type & channel Transaction DB / CBS Existing Batch Stream Required
Counterparty name / account Transaction DB Existing Batch Required
Document scan / photo Onboarding system / DMS New API Optional (enhances accuracy)
Existing risk classification CBS / Compliance system Existing Batch Optional (used as baseline)

Security & Data Handling

🔐

Encrypted in transit

All API calls use TLS 1.3. Mutual certificate authentication between your CBS and our gateway: no plain HTTP, no shared passwords.

🏗️

Encrypted at rest

Customer data stored on our bare-metal servers uses AES-256 encryption. Encryption keys are held inside Nepal, not by a third-party cloud provider.

🇳🇵

Data never leaves Nepal

All processing runs on hardware physically located inside carrier-grade colocation facilities in Nepal. No data is routed through international servers.

📝

Full audit trail

Every API call, every analysis result, and every compliance decision is logged with timestamp and officer ID, ready for NRB inspection at any time.

🚪

Read-only access

Our platform only reads from your CBS. We never write back to your core banking system. Your data is the source of truth; we only analyse it.

📋

Data sharing agreement

A formal Data Processing Agreement is signed before any integration begins, defining exactly what data we access, how long we retain it, and deletion procedures.

How the Pilot Integration Works in Practice

We don't ask for production database access on day one. The pilot follows a safe, staged process:

1
Sandbox environment (Weeks 1–4)Your IT team shares anonymised or synthetic customer data matching your real CBS schema. We build and test the integration against your data format without touching live records.
2
Data Processing Agreement signedLegal teams agree on data scope, retention periods, deletion obligations, and NRB compliance responsibilities before any real data is shared.
3
Limited production pilot (Weeks 5–12)Integration goes live for a defined subset (for example, new customer onboarding only, or a single branch) before full rollout. Results are reviewed weekly with your compliance team.
4
Full rolloutOnce the pilot validates accuracy and workflow fit, integration expands to all customer accounts and all transaction monitoring.
What we need from your IT team to start the sandbox A sample of 50–100 anonymised customer records and 500–1,000 anonymised transactions in whatever format your CBS currently exports (CSV, JSON, or XML). This is enough to validate the full integration flow without any real customer data leaving your systems.
PoC stage: honest framing The DONIDCR National ID API integration requires a formal government agreement that is still being pursued. During the PoC phase, identity verification uses document consistency checks and stated-data analysis only. The goAML STR submission integration is also in scoping: STR drafts are currently produced for compliance officer review and manual submission.
What the bank's IT team does not need to build You do not need to modify your core banking system. The integration is a one-way data feed from your existing export capabilities. If your CBS can export a CSV or call a REST API, the integration is already possible.
Next: platform layer
VajraCore Overview →
Then try it live
Live KYC/AML Platform →
VajraCloudAI · Bank Data Ingestion Flow · Confidential / Internal Distribution Only · © 2026