Security and Fraud - mdoujak/A2AP GitHub Wiki

Security and Fraud

A key strength of A2A payments is the enhanced security model, especially when Self-Sovereign Identity (SSI) is used to identify both the merchant and the bank. By leveraging SSI, each participant in the transaction can be cryptographically verified through decentralized credentials, ensuring that only trusted entities are involved in the payment flow. This eliminates anonymity and significantly reduces the risk of fraud, phishing, and spoofing attacks. Unlike traditional card payments, where fraud often involves compromised card data, A2A payments with SSI provide end-to-end identity assurance, reinforcing trust while maintaining privacy and regulatory compliance.

Security Features

To take full advantage of the E-ID trust infrastructure, the following functionality must be implemented:

  • Merchant

    • The merchant must be a member in at least one trusted ecosystem in Switzerland. This membership enables the merchant to obtain a trust credential, to prove both identity and trustworthiness.
      • Both Customer and Bank will verify the DID against the trust infrastructure.
    • The bill VC offered by the merchant to the customer must be linked to the trust credential of the merchant (i.e. it must reference the same DID).
      • The signature of the bill must link the bill and the trust credential with the same DID.
    • The payment promise provided by the bank is verified by the merchant. It will only be accepted, if the bank is trusted.
  • Customer

    • The wallet of the customer should verify the validity and integrity of both the bill VC and the trust credential of the merchant. This is optional as the real verification is handled by the bank.
    • The proof, presented by the customer to the bank, will contain the bill VC, the trust credential of the merchant, the account VC of the bank, and the consent of the customer.
  • Bank

    • The bank must be a member in at least one trusted ecosystem in Switzerland. This membership enables the bank to obtain a trust credential, to prove both identity and trustworthiness.
    • The bank will validate the proof presented by the customer as follows:
      • The proof must:
        • contain all the necessary claims (e.g. the bill)
        • be valid
        • integrity must verify
        • link to the customer credential must verify
      • the bill (from the proof( must:
        • contain all the necessary claims (schema conformance)
        • contain the DID of the merchant
      • the DID of the merchant must
        • be valid in the trust infrastucture
      • ...
    • If the validation of the proof was successful, the bank will issue a payment promise. This promis will contain the following information:
      • the bill
      • the condition of the payment promise (source IBAN, destination IBAN, amount, currency)
      • the payment promise must be linked to the trust credential of the bank

Fraud

The above features will make fraud particularly difficult for the following reasons:

  • The bank can identify and verify the merchant.
  • The merchant can identify and verify the bank.

If a fraudster manages to phish a customer successfully the checks of the bank will make it almost impossible to abuse this payment scheme for fraudulent purposes. A successful fraudster would need to obtain fraudulent trust credentials from a trusted ecosystem. This should be extremely difficult to achieve, if the governance processes of the ecosystem are implemented correctly.