W3G8 — Modern Core Banking Infrastructure

Features

Everything you need to move money

A full-stack platform covering payments, compliance, FX, fees, and settlement in one unified architecture.

Multi-Asset Ledger

Double-entry accounting across fiat, crypto, and tokenized assets with real-time balance queries.

Global Payments

Connect to SWIFT, SEPA, ACH, RTP, card networks, and blockchain rails through a single API.

Built-in Compliance

Sanctions screening, AML monitoring, and regulatory reporting embedded in every transaction flow.

Rules Engine

Declarative business rules for fees, routing, limits, and compliance. Change behavior without code deployments.

FX & Conversion

Real-time rate sourcing, conversion execution, and margin calculation across 150+ currency pairs.

Settlement

Automated reconciliation, nostro/vostro management, and end-of-day settlement via settle.cloud.

Architecture

Event-driven microservices built for scale

A composable core banking platform aligned to BIAN service domains. Every component is independently deployable, horizontally scalable, and connected through an asynchronous event bus.

Channels & Consumers

Mobile

Web

API

Batch

          
          w3g8 API Gateway
          Auth · Rate Limiting · Routing

          
          Event Bus (Message-Oriented Middleware)
          Topics · DLQ · Event Replay

Core Services

Rules Engine

Ledger

Payments

Compliance

Fees

External Payment Rails

SWIFT

SEPA

ACH

RTP

Cards

Crypto

          
          settle.cloud
          Reconciliation · Settlement Engine · Nostro/Vostro

Event-Driven

All services communicate through asynchronous events. No direct service-to-service calls.

BIAN Aligned

Service domains and API naming follow the Banking Industry Architecture Network taxonomy.

Multi-Tenant

Isolated data, independent rule sets, and dedicated ledger partitions per tenant.

Standards-Based

ISO 20022 for cross-border messaging. ISO 8583 for card transactions. CloudEvents on the bus.

Rules Engine

Change behavior without code rewrites

Business logic -- fees, routing, limits, compliance checks -- is expressed as declarative rules, not application code. Author, test, and deploy rules independently of service releases.

Author

Write rules in
declarative YAML

→

Validate

Schema & conflict
checks

→

Test

Sandbox with
synthetic data

→

Shadow

Run against live
traffic, no effect

→

Deploy

Promote to
production

Sample Rule Definition

rule:
  id: high-value-intl-wire
  version: 3

  when:
    - transaction.amount > 50000
    - transaction.corridor == "INTERNATIONAL"

  then:
    - apply_fee:
        type: PERCENTAGE
        value: 0.15
    - require_approval: SENIOR_OPS
        

What this rule does

When an international wire transfer exceeds $50,000:

1. Apply a 0.15% fee to the transaction amount
2. Route for senior operations approval
3. Full audit trail logged automatically

Traditional Approach vs W3G8 Rules Engine

Aspect	Traditional Approach	W3G8 Rules Engine
Change a fee	Code change, transport, regression test, deploy	Edit rule YAML, review, promote
Add routing rule	Modify program logic, test all paths	Add new rule, existing rules unaffected
Audit trail	Manual documentation	Automatic -- every version and execution logged
Rollback	Restore transport, redeploy	One-click revert to previous rule version

Services

Independent services, unified platform

Each service maps to a BIAN service domain, owns its data, scales independently, and communicates exclusively through the event bus. Deploy any service without affecting the rest.

Ledger

Multi-asset double-entry accounting
Real-time balance queries
Event-sourced posting history

/v1/accounts

Payments

Payment initiation and orchestration
Status tracking and notifications
Intelligent rail selection

/v1/payments

Rules Engine

Declarative rule evaluation
Version control and audit
Shadow mode testing

/v1/rules

Compliance

Sanctions screening (OFAC, EU, UN)
AML monitoring and alerts
Regulatory reporting

/v1/screening

FX

Multi-source rate aggregation
Conversion execution
Margin and spread calculation

/v1/rates

Fees

Rule-driven fee calculation
Tiered and volume-based pricing
Revenue tracking and reporting

/v1/fee-schedules

Notifications

Webhooks and event subscriptions
Email, SMS, push channels
Delivery tracking and retry

/v1/subscriptions

Settlement Bridge

settle.cloud integration
Automated reconciliation
Nostro/vostro management

/v1/settlement

Gateway

Auth, rate limiting, throttling
Request routing and load balancing
Protocol translation

api.w3g8.com

KYX Engine

Context-driven KYC & KYB

Different products, customers, and situations require different verification levels. The KYX engine dynamically determines the right KYC (individual) or KYB (business) flow based on context -- not rigid, one-size-fits-all rules.

Context Dimensions That Drive Verification

Product Context

What you're doing — AIS (account info) needs strong consent but less funds-risk controls. PIS (payment initiation) needs stronger fraud protection. Wallets need ongoing monitoring.

AIS PIS Wallet Acquiring

Customer Type

Who they are — Individuals need KYC (identity + screening). Companies need KYB (entity + UBOs + directors). Sole traders are hybrid. Regulated entities may use simplified checks.

Individual Sole Trader Company

Geography & Corridor

Where they are — Country risk (FATF lists, sanctions), cross-border vs domestic flows, and residency mismatches (ID country ≠ address ≠ IP) all affect risk scoring.

Sanctions FATF Lists Corridors

Channel & Session

How they connect — Web vs mobile vs API partner, device reputation, IP risk, emulators, velocity of signups. Weaker channel assurance triggers earlier step-up.

Web Mobile API Partner

Behavior & Value

What happens over time — Cumulative volume, velocity, and patterns drive upgrade paths. Thresholds trigger progressive verification requirements.

€0-250 SDD €1k+ CDD €10k+ EDD

Risk Signals

What triggers step-up — New payee, device change, login anomaly, velocity spike, payee in high-risk country. PSD2-style triggers for dynamic verification.

New Payee Device Change Anomaly

Verification Levels

KYC Levels (Individual)

SDD — Simplified Due Diligence

Basic identity capture + PEP/Sanctions screening. For low-value, low-risk scenarios.

CDD — Customer Due Diligence

PEP/Sanctions + ID document verification. Standard baseline for wallets and payments.

CDD+ — Enhanced CDD

CDD + address verification + tighter consistency checks. Triggered by risk signals.

EDD — Enhanced Due Diligence

CDD+ + Liveness + Source of Funds/Wealth + manual review. Senior sign-off required.

KYB Levels (Business)

BASIC

Company registration + Directors/UBOs identified + Controller screening + Basic business info.

STANDARD

Basic + Business model narrative + Flow of funds + Expected volumes + Proof of trading.

ENHANCED

Standard + SoF/SoW at entity level + Ownership graph verification + Site visit + Senior approval.

Complexity triggers: UBO chain >2 layers, trusts/nominees, high-risk country controllers, newly formed + high volume, unclear purpose.

Step-Up Triggers

Trigger	Level Upgrade	Checks Required
Product baseline (Wallet/IBAN)	CDD	PEP/Sanctions screening
Lifetime total > €1,000	CDD	ID doc verification + PEP/Sanctions
New payee + txn ≥ €500	CDD+	ID doc verification (+ Liveness if device anomaly)
High-risk geo mismatch	CDD+ → EDD	ID doc verification + Liveness
Sanctions hit	EDD / Block	Confirm screening + Create case + Soft/hard block
Ownership layers ≥ 3 (KYB)	ENHANCED	Business registry + UBO screening + Case
High-risk MCC (Acquiring)	ENHANCED	Business registry + UBO screening + Adverse media

Sample KYX Rule

# Step-up for new payee + high amount
rule:
  id: stepup_new_payee_high_amount
  priority: 80
  scope:
    products: [PIS, WALLET, IBAN]
    customer_types: [INDIVIDUAL]

  when:
    all:
      - path: signals.new_payee
        op: eq
        value: true
      - path: volumes.txn_amount
        op: gte
        value: 500

  then:
    - set_levels:
        kyc_level: CDD_PLUS
        reason_codes: [NEW_PAYEE_STEPUP]
    - require_checks:
        checks: [ID_DOC_VERIFICATION]
    - emit:
        subject: kyx.evt.stepup.required.v1
        

What This Rule Does

When a customer initiates a payment to a new payee for €500 or more:

1. Upgrade KYC level to CDD+ (enhanced due diligence)
2. Require ID document verification before proceeding
3. Emit step-up event to NATS for downstream services
4. Full audit trail with reason codes for compliance

Note: Levels only upgrade (SDD < CDD < CDD+ < EDD). Downgrades require explicit authorization.

Volume-Based Thresholds

€0 - 250

Light SDD
Basic screening

→

€250 - 1k

Standard SDD
Enhanced screening

→

€1k - 5k

CDD Trigger
ID verification

→

€5k - 10k

Soft EDD
Manual review

→

> €10k

Full EDD
SoF/SoW required

→

> €50k

Blocked
Pre-approval only

Technical Spec

KYX Rules & Event Architecture

Concrete rule schemas, NATS subject naming conventions, and Plato integration contracts for implementing context-driven KYC/KYB.

Input Events (Into KYX Engine)

customer.evt.created.v1

transaction.evt.created.v1

auth.evt.session.risk.v1

screening.evt.hit.v1

          
          KYX Rules Engine
          Context Evaluation · Level Determination · Check Orchestration

Output Events (From KYX Engine)

kyx.evt.level.required.v1

kyx.evt.checks.required.v1

kyx.evt.stepup.required.v1

kyx.evt.case.created.v1

Plato Integration

kyx.cmd.plato.check.request.v1

kyx.evt.plato.check.result.v1

NATS Subject Naming

Commands (kyx.cmd.*)

kyx.cmd.plato.check.request.v1

Commands request actions from downstream services (e.g., ask Plato to run a verification check).

Events (kyx.evt.*)

kyx.evt.level.required.v1
kyx.evt.checks.required.v1
kyx.evt.stepup.required.v1
kyx.evt.case.created.v1
kyx.evt.plato.check.result.v1
kyx.evt.review.scheduled.v1

Events notify what happened. Compliance UI subscribes to kyx.evt.*.v1

Message Envelope

{
  "meta": {
    "event_id": "01HZY8Z6QG7YJ4A1Z0R9K9R2VX",
    "event_type": "kyx.evt.level.required.v1",
    "occurred_at": "2026-02-03T10:22:31.123Z",
    "tenant_id": "tenant_demo",
    "correlation_id": "corr_7b2c0b1e",
    "causation_id": "evt_abc123",
    "idempotency_key": "kyx:level:customer_123:rule_eval:2026-02-03",
    "producer": "kyx-rules-engine",
    "schema_version": 1
  },
  "actor": { "actor_type": "SYSTEM", "actor_id": "kyx-engine" },
  "subject": { "customer_id": "customer_123", "org_id": null },
  "data": { /* payload specific to event type */ }
}
    

Plato Integration Matrix

Check Type	SDD	CDD	CDD+	EDD
PEP_SANCTIONS_SCREEN	✓	✓	✓	✓
ID_DOC_VERIFICATION	—	✓	✓	✓
ADDRESS_VERIFICATION	—	—	✓	✓
LIVENESS	—	—	conditional	✓
SOURCE_OF_FUNDS	—	—	—	✓
VIDEO_INTERVIEW	—	—	—	if needed

KYB Checks by Level

Check Type	BASIC	STANDARD	ENHANCED
BUSINESS_REGISTRY	✓	✓	✓
UBO_SCREENING	✓	✓	✓
PROOF_OF_TRADING	—	✓	✓
ADVERSE_MEDIA	—	optional	✓
OWNERSHIP_GRAPH	—	—	✓
ENTITY_SOF_SOW	—	—	✓

Rule Action Types

set_levels

Set KYC/KYB required levels (only upgrades unless explicitly allowed)

require_checks

Attach required verification checks (Plato or internal)

emit

Emit an event to NATS (subject + payload)

create_case

Route to compliance queue with SLA

schedule_review

Set periodic/triggered refresh cadence

block

Soft or hard blocking (SOFT/HARD)

set_risk_score

Set absolute risk score value

add_risk_points

Add incremental risk points

Condition DSL Operators

eq neq gt gte lt lte in not_in contains not_contains exists matches

Combine with all, any, and not for complex conditions.

Standardized Status Enums

PASS FAIL REVIEW PENDING EXPIRED ERROR

Migration

From legacy to modern, module by module

Migrating from SAP or legacy core banking does not require a big bang. W3G8 uses the strangler fig pattern to wrap and replace payment functions incrementally, one module at a time.

SAP Module Mapping

SAP Modules

FI - Financial Accounting

TR - Treasury

BCA - Bank Customer Accounts

CO - Controlling

MM - Materials Management

SD - Sales & Distribution

HR - Human Resources

PP - Production Planning

W3G8 Services

Ledger + Payment Service

Ledger + FX + Settlement

Ledger + Rules Engine

Retained in SAP or migrated to other systems

Migration Phases

Parallel Run

Connect W3G8 to existing payment rails
Mirror SAP transactions to W3G8 ledger
Validate balances match daily

Rules Migration

Extract business rules from ABAP
Translate to declarative YAML format
Shadow-test against live SAP decisions

Traffic Shift

Route new payment types through W3G8
SAP becomes secondary for payments
Expand to more corridors incrementally

Cutover

W3G8 is primary for all payments
SAP retained for non-payment modules
Decommission SAP payment components

Payments infrastructure built for modern banks

Everything you need to move money

Multi-Asset Ledger

Global Payments

Built-in Compliance

Rules Engine

FX & Conversion

Settlement

From integration to live in weeks

Connect

Configure

Test

Go Live

Event-driven microservices built for scale

Event-Driven

BIAN Aligned

Multi-Tenant

Standards-Based

Change behavior without code rewrites

Author

Validate

Test

Shadow

Deploy

Sample Rule Definition

What this rule does

Traditional Approach vs W3G8 Rules Engine

Independent services, unified platform

Ledger

Payments

Rules Engine

Compliance

FX

Fees

Notifications

Settlement Bridge

Gateway

Context-driven KYC & KYB

Context Dimensions That Drive Verification

Product Context

Customer Type

Geography & Corridor

Channel & Session

Behavior & Value

Risk Signals

Verification Levels

KYC Levels (Individual)

KYB Levels (Business)

Step-Up Triggers

Sample KYX Rule

What This Rule Does

Volume-Based Thresholds

€0 - 250

€250 - 1k

€1k - 5k

€5k - 10k

> €10k

> €50k

KYX Rules & Event Architecture

NATS Subject Naming

Commands (kyx.cmd.*)

Events (kyx.evt.*)

Message Envelope

Plato Integration Matrix

KYB Checks by Level

Rule Action Types

set_levels

require_checks

emit

create_case

schedule_review

block

set_risk_score

add_risk_points

Condition DSL Operators

Standardized Status Enums

Every change validated before production

Testing Pyramid

Rule Testing Pipeline

Quality Gates