⚠ Pre-Approval Preview

This website is under construction. The information described here is indicative only, subject to change, and must not be relied upon. The AvatarPay platform is still under active development.

Security Architecture

The Verified Account
Sort Code

AvatarPay replaces the UK's static 6-digit sort code and 8-digit account number with a Dynamic Verified Identifier (DVI) - a short code engineered to materially reduce invoice tampering and APP fraud.

The Problem

Invoice tampering and APP fraud are critical issues in the UK

Fraudsters use Business Email Compromise (BEC) to intercept legitimate invoices and replace the bank details with their own accounts. In a typical UK transaction, sort codes and account numbers are static - making them easy to spoof or replace in a PDF invoice.

Authorised Push Payment (APP) fraud exploits this. The payer is deceived into authorising a payment to a fraudster's account. Once the funds leave, the reclaim process is lengthy and uncertain - because the underlying ledger records the transaction as legitimate.

AvatarPay's Account Number Short Code is a strategic innovation designed to render these attacks obsolete. It is a tangible solution to a multi-billion-pound problem that no UK banking competitor has yet solved at the ledger level.

Current UK system - how BEC works

  1. Supplier sends legitimate invoice with real bank details (sort code + account number)
  2. Fraudster intercepts email, replaces bank details with their own account
  3. Payer sees the correct supplier name but wrong account details - no system validation
  4. Payment authorised and settled to fraudster's account
  5. Reclaim process begins - weeks or months, with uncertain recovery

AvatarPay - how the DVI stops this

  1. Supplier provides their Dynamic Verified Identifier (DVI) - not a static account number
  2. Fraudster alters the DVI in the invoice
  3. Payer enters the altered DVI into AvatarPay
  4. On-chain verification: altered DVI does not match the supplier's verified public key on the smart contract ledger
  5. Payment refused before a single penny moves. Fraud attempt logged.
How It Works

The Dynamic Verified Identifier (DVI) flow

Every payment goes through identity verification before a single penny moves. The process is instant - sub-second - and invisible to the end user.

01

Short Code Generated

A Dynamic Verified Identifier (DVI) is generated - a truncated, human-readable code linked to a specific transaction or supplier relationship.

02

Linked to Decentralised Identity

The DVI is bound to the recipient's decentralised identity (DID) and their verified public key on the smart contract ledger.

03

Payer Enters Code

The paying party enters the short code. AvatarPay does not simply look up a bank account - it performs a decentralised on-chain verification.

04

Identity Verified On-Chain

The system checks that the code matches the recipient's verified public key. Any invoice tampering breaks this match.

05

Match → Payment Proceeds

Identity confirmed. Smart contract authorises funds transfer. Sub-second settlement. Immutable record written.

06

No Match → Payment Blocked

Code does not match the recipient's on-chain identity. Payment refused. Spoofing transfer attempt logged and flagged.

Enhanced Verification

Anti-tampering tools across the entire payment lifecycle

The DCI is the first line of defence. AvatarPay layers additional verification and anomaly detection to secure every stage.

🔍

Automated Supplier Validation

Real-time checking of tax IDs and banking details before a vendor is added to the system. No manual process, no human error window.

🤖

AI-Powered Anomaly Detection

Machine learning identifies patterns of invoice fraud - including inflated or fraudulent invoices submitted for services never rendered.

🛡️

Two-Factor Authentication for Data Changes

Any change to critical supplier data - such as an account number - must be verified through biometric or hardware-based MFA before it takes effect.

🪪

Decentralised Identity (DID) Verification

Every recipient has a verified decentralised identity on the smart contract ledger. Payments resolve to identities, not editable text fields.

Regulatory Positioning

FSCS vs Safeguarding vs Protocol-Level Integrity

Traditional banking protects funds after a failure. AvatarPay's Advanced Banking architecture is designed to address the primary failures - mispayments and fraud - before they occur. The protocol enforces the rules.

FeatureFSCS (Licensed Bank)Safeguarding (EMI)AvatarPay Advanced
Protection MechanismFSCS deposit insurance (up to £120,000)100% balance safeguarded in regulated bankProtocol-level integrity via decentralised consensus
Recovery Time if FailureWeeks to monthsYears (liquidation process)Real-time settlement - no insolvency risk by design
Lending RiskHigh (fractional reserve lending)Low (no lending)Zero - smart contract escrow model
Central Point of FailureYes - single licensed institutionYes - partner bankNo - distributed across decentralised nodes
Wrong Payment RecoveryLengthy manual reclaim processLengthy manual reclaim processPrevented at source - blocked before authorisation
Invoice Tampering DefenceNone - static account numbersNone - static account numbersDVI identity verification - blocked on mismatch

AvatarPay's position: Building Advanced Banking with less reliance on FSCS after-the-fact compensation. In a decentralised system, payment rules are enforced by the protocol. On-chain assets serve as an immediate liquidity pool, and no central point of failure means no single firm can "go bust" and lose all data. The trade-off is clear: less traditional deposit insurance, in exchange for a platform that addresses mispayments and spoofing at the source.

See how AvatarPay compares to legacy banking

The feature comparison shows precisely where Advanced Banking outperforms traditional and EMI banking models.