Variable Recurring Payments: A Technical Deep Dive for Developers

Variable Recurring Payments (VRPs) represent the most significant evolution in UK payment infrastructure since the introduction of Faster Payments. Unlike traditional payment methods, VRPs combine the convenience of Direct Debit with the control and transparency of Open Banking - putting genuine power back in the hands of consumers while opening new possibilities for payment service providers.

This technical guide is aimed at developers and architects building VRP-enabled services. We'll cover the underlying APIs, consent architecture, security requirements, and implementation patterns you'll need to get it right.

What Makes VRPs Different

Before diving into the technical details, it's worth understanding where VRPs sit in the payments landscape:

The key innovation is the long-lived consent with explicit boundaries. A consumer authorises a Third Party Provider (TPP) to initiate payments on their behalf, but within strict parameters they define: maximum amount per payment, maximum cumulative amount per period, and permitted frequency.

The UK VRP Regulatory Context

VRPs in the UK operate under the Open Banking standards originally defined by OBIE, with regulatory oversight from both the FCA and the Payment Systems Regulator (PSR). The initial rollout focused on sweeping use cases - moving money between accounts held by the same person - mandated for the CMA9 banks from July 2022.

The expansion to non-sweeping VRPs (commercial VRPs) is now underway, covering use cases like subscription payments, utility bills, and merchant payments. This is where the real disruption lies - and where the technical complexity increases significantly.

API Architecture Overview

The VRP API builds on the existing Open Banking Payment Initiation Services (PIS) specification, with extensions for recurring consent management. The key resources are:

• domestic-vrp-consents - Create and manage VRP consent objects
• domestic-vrps - Initiate individual payments under an existing consent
• domestic-vrps/{DomesticVRPId} - Retrieve payment status and execution details

All VRP endpoints require FAPI 1.0 Advanced compliance (with FAPI 2.0 adoption expected as UK regulators update their guidance). This means mandatory mTLS, signed request objects, and sender-constrained access tokens.

Consent Lifecycle

The VRP consent flow follows a familiar OAuth pattern but with additional complexity around the consent parameters. Here's the sequence:

┌─────────┐     ┌─────────┐     ┌─────────┐     ┌─────────┐
│   PSU   │     │   TPP   │     │  ASPSP  │     │  ASPSP  │
│ (User)  │     │ (PISP)  │     │  (API)  │     │  (Auth) │
└────┬────┘     └────┬────┘     └────┬────┘     └────┬────┘
     │               │               │               │
     │  Initiate     │               │               │
     │  VRP Setup    │               │               │
     │──────────────>│               │               │
     │               │               │               │
     │               │ POST          │               │
     │               │ /domestic-vrp-│               │
     │               │ consents      │               │
     │               │──────────────>│               │
     │               │               │               │
     │               │ ConsentId +   │               │
     │               │ Status:       │               │
     │               │ AwaitingAuth  │               │
     │               │<──────────────│               │
     │               │               │               │
     │               │ Redirect to   │               │
     │               │ ASPSP Auth    │               │
     │<──────────────│──────────────────────────────>│
     │               │               │               │
     │  Authenticate │               │               │
     │  + Review     │               │               │
     │  Consent      │               │               │
     │  Parameters   │               │               │
     │──────────────────────────────────────────────>│
     │               │               │               │
     │  Redirect     │               │               │
     │  back to TPP  │               │               │
     │<──────────────│<──────────────────────────────│
     │               │               │               │
     │               │ Exchange code │               │
     │               │ for tokens    │               │
     │               │──────────────────────────────>│
     │               │               │               │
     │               │ Access Token  │               │
     │               │ + Refresh     │               │
     │               │<──────────────────────────────│
     │               │               │               │

The critical difference from single payments is that the refresh token returned is long-lived - typically valid for the duration of the consent (which can be months or years). Access tokens remain short-lived (minutes to hours) and must be refreshed. The TPP stores these tokens securely and uses them to initiate payments without further PSU interaction.

Creating a VRP Consent

The consent creation request defines the boundaries within which payments can be initiated. Here's an example request body:

{
  "Data": {
    "ReadRefundAccount": "Yes",
    "ControlParameters": {
      "ValidFromDateTime": "2026-06-01T00:00:00Z",
      "ValidToDateTime": "2027-05-31T23:59:59Z",
      "MaximumIndividualAmount": {
        "Amount": "100.00",
        "Currency": "GBP"
      },
      "MaximumCumulativeAmount": {
        "Amount": "500.00",
        "Currency": "GBP"
      },
      "MaximumCumulativeNumberOfPayments": 20,
      "PeriodicLimits": [
        {
          "PeriodType": "Month",
          "PeriodAlignment": "Calendar",
          "MaximumAmount": {
            "Amount": "200.00",
            "Currency": "GBP"
          },
          "MaximumNumberOfPayments": 10
        }
      ]
    },
    "Initiation": {
      "CreditorAccount": {
        "SchemeName": "UK.OBIE.SortCodeAccountNumber",
        "Identification": "30949330000010",
        "Name": "ACME Subscriptions Ltd"
      },
      "RemittanceInformation": {
        "Reference": "ACME-SUB-12345"
      }
    }
  },
  "Risk": {
    "PaymentContextCode": "BillPayment",
    "MerchantCategoryCode": "5411",
    "MerchantCustomerIdentification": "customer-12345"
  }
}

The ControlParameters object is the heart of VRP security. Note the multiple layers of protection:

• ValidFromDateTime / ValidToDateTime - Absolute time bounds for the consent
• MaximumIndividualAmount - Cap on any single payment
• MaximumCumulativeAmount - Total spend limit across the consent lifetime
• MaximumCumulativeNumberOfPayments - Total payment count limit
• PeriodicLimits - Rolling limits within defined periods (day, week, month, year)

Initiating a Payment

Once you have an authorised consent and a valid access token, initiating a payment is straightforward. The ASPSP validates the payment against the consent parameters before processing:

POST /domestic-vrps
Authorization: Bearer {access_token}
x-idempotency-key: {unique-request-id}
x-jws-signature: {detached-jws}

{
  "Data": {
    "ConsentId": "vrp-consent-88379",
    "PSUAuthenticationMethod": "UK.OBIE.SCA",
    "Initiation": {
      "CreditorAccount": {
        "SchemeName": "UK.OBIE.SortCodeAccountNumber",
        "Identification": "30949330000010",
        "Name": "ACME Subscriptions Ltd"
      },
      "RemittanceInformation": {
        "Reference": "ACME-SUB-12345-JAN"
      }
    },
    "Instruction": {
      "InstructionIdentification": "instr-2027-01-23-001",
      "EndToEndIdentification": "e2e-sub-payment-jan",
      "LocalInstrument": "UK.OBIE.FPS",
      "InstructedAmount": {
        "Amount": "29.99",
        "Currency": "GBP"
      },
      "CreditorAccount": {
        "SchemeName": "UK.OBIE.SortCodeAccountNumber",
        "Identification": "30949330000010",
        "Name": "ACME Subscriptions Ltd"
      }
    }
  },
  "Risk": {
    "PaymentContextCode": "BillPayment"
  }
}

Key implementation notes:

• Idempotency - The x-idempotency-key header is mandatory. ASPSPs must return the same response for duplicate requests within their idempotency window (typically 24 hours). Generate a unique key per payment attempt and store it with your payment record.
• JWS Signature - The x-jws-signature contains a detached JWS signature over the request body, signed with your OBWAC or OBSeal certificate.
• Instruction vs Initiation - The Initiation block must match what was specified in the consent. The Instruction block contains the variable elements for this specific payment.

Handling the Response

A successful payment initiation returns a 201 Created with the payment resource:

{
  "Data": {
    "DomesticVRPId": "vrp-payment-12345",
    "ConsentId": "vrp-consent-88379",
    "CreationDateTime": "2027-01-23T10:30:00Z",
    "Status": "AcceptedSettlementInProcess",
    "StatusUpdateDateTime": "2027-01-23T10:30:01Z",
    "ExpectedExecutionDateTime": "2027-01-23T10:30:00Z",
    "ExpectedSettlementDateTime": "2027-01-23T10:30:00Z",
    "Refund": {
      "Account": {
        "SchemeName": "UK.OBIE.SortCodeAccountNumber",
        "Identification": "20202012345678",
        "Name": "J Smith"
      }
    },
    "Charges": [
      {
        "ChargeBearer": "BorneByDebtor",
        "Type": "UK.OBIE.FasterPayments",
        "Amount": {
          "Amount": "0.00",
          "Currency": "GBP"
        }
      }
    ],
    "Initiation": { ... },
    "Instruction": { ... },
    "DebtorAccount": {
      "SchemeName": "UK.OBIE.SortCodeAccountNumber",
      "Identification": "20202012345678",
      "Name": "J Smith"
    }
  },
  "Links": {
    "Self": "https://api.bank.co.uk/open-banking/pisp/domestic-vrps/vrp-payment-12345"
  }
}

The Status field follows the ISO 20022 payment status lifecycle. Common values include:

• AcceptedSettlementInProcess - Payment accepted, settlement pending
• AcceptedSettlementCompleted - Settlement confirmed
• Rejected - Payment failed validation or was rejected by the scheme

Consent Parameter Validation

ASPSPs perform real-time validation of each payment against the consent parameters. A payment will be rejected if it would breach any limit. Your implementation must handle these rejections gracefully:

{
  "Code": "UK.OBIE.Rules.FailsControlParameters",
  "Message": "Payment would exceed MaximumCumulativeAmount",
  "Path": "Data.Instruction.InstructedAmount.Amount",
  "Url": "https://api.bank.co.uk/errors/vrp/limit-exceeded"
}

Common rejection reasons include:

• Individual payment amount exceeds MaximumIndividualAmount
• Cumulative amount would exceed MaximumCumulativeAmount
• Payment count would exceed MaximumCumulativeNumberOfPayments
• Periodic limit breach (e.g., monthly cap reached)
• Payment outside ValidFromDateTime / ValidToDateTime window
• Consent revoked by PSU
• Insufficient funds in debtor account

Your system should track cumulative usage locally to avoid unnecessary API calls, but always be prepared for ASPSP-side rejections as the authoritative source of truth.

Token Management

VRP refresh tokens are long-lived but not immortal. You need robust token management:

• Refresh tokens - VRP consents typically rely on refresh tokens that remain valid for the duration of the consent. Access tokens are short-lived (often minutes) and must be refreshed. Implement automatic refresh and handle refresh token rotation where banks issue a new refresh token on refresh.
• Token storage - Access tokens must be stored encrypted at rest. Consider using a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault) rather than your application database.
• Revocation handling - PSUs can revoke consent at any time via their bank. Your next payment attempt will fail with a 401 or 403. Handle this by marking the consent as revoked and notifying the customer.

Webhooks and Notifications

The OBIE Event Notification API allows ASPSPs to push status updates to TPPs. For VRPs, key events include:

• urn:uk:org:openbanking:events:domestic-vrp-consent-revoked
• urn:uk:org:openbanking:events:domestic-vrp-payment-completed
• urn:uk:org:openbanking:events:domestic-vrp-payment-rejected

Webhook support varies by ASPSP. Implement polling as a fallback for banks that don't support push notifications. A typical polling interval is every 5-15 minutes for pending payments.

Security Considerations

VRPs carry elevated risk compared to single payments - a compromised TPP could drain customer accounts within the consent limits. Security must be defence-in-depth:

• mTLS everywhere - All ASPSP communication must use mutual TLS with your OBWAC certificate. Validate certificate chains rigorously.
• Request signing - Sign all requests with detached JWS using your OBSeal certificate. Validate response signatures where provided.
• Minimum viable consent - Request only the parameters you need. Don't ask for £10,000/month limits if £100/month suffices.
• Anomaly detection - Monitor payment patterns. Flag unusual activity (time of day, frequency, amounts) for review.
• Key rotation - Rotate signing keys and certificates before expiry. The OBIE Directory supports key rollover without service interruption.

Testing and Certification

Before going live, you'll need to:

1. Register with the OBIE Directory - Obtain your software statement assertion (SSA) and certificates.
2. Test in sandbox environments - All CMA9 banks provide sandbox APIs. The OBIE also maintains a conformance suite for VRP validation.
3. Complete DCR with each ASPSP - Dynamic Client Registration creates your OAuth client at each bank.
4. Run conformance tests - The OBIE functional conformance tool validates your implementation against the specification.

Implementation Checklist

Before launching VRP support, ensure you have:

• Valid OBWAC and OBSeal certificates from a qualified trust service provider
• Software statement registered in the OBIE Directory
• DCR completed with target ASPSPs
• mTLS configured correctly (certificate chain, hostname verification)
• JWS signing and verification implemented
• Idempotency key generation and storage
• Token storage with encryption at rest
• Token refresh automation
• Consent parameter validation (local tracking)
• Error handling for all OBIE error codes
• Webhook endpoint (or polling fallback)
• Consent revocation handling
• Audit logging for all payment operations
• Monitoring and alerting for failures

Looking Ahead

VRPs are still maturing. Key developments to watch include:

• Non-sweeping VRP rollout - The PSR is pushing for commercial VRP adoption. Expect evolving requirements around liability, dispute resolution, and pricing.
• FAPI 2.0 migration - As UK regulators adopt FAPI 2.0, expect changes to token binding requirements (DPoP vs mTLS) and consent management.
• Cross-border VRPs - The EU's PSD3/PSR1 proposals include VRP-like capabilities. Interoperability between UK and EU schemes remains an open question.

In Part 2, we'll explore the political and commercial dynamics shaping VRP adoption - including the regulatory battles, competitive tensions, and consumer protection debates that will determine how this technology evolves.