Banking & payments domain

19.1 The payments landscape in Australia Added

Several rails move money between banks. Each one clears (swaps payment messages) and then settles (moves real money between the banks' accounts at the RBA).

• AusPayNet (Australian Payments Network) is the industry's self-regulatory body. It administers frameworks such as BECS and HVCS.
• AP+ brings BPAY, eftpos and NPP Australia under one company. The ACCC authorised the amalgamation in 2021.
• The RBA runs RITS, regulates the payments system (through its Payments System Board) and oversees the big rails.

19.2 NPP, Osko & PayID Added

The New Payments Platform is Australia's fast-payment rail: account-to-account payments in seconds, 24/7, with rich ISO 20022 data and simple PayID addressing.

Typical bank integration (generic)

// Scheme gateway client: fail fast, never blindly retry a send
builder.Services.AddHttpClient<NppGatewayClient>(c => c.BaseAddress = new(gatewayUrl))
    .AddResilienceHandler("npp-gateway", pipeline =>
    {
        pipeline.AddTimeout(TimeSpan.FromSeconds(5));          // whole attempt
        pipeline.AddCircuitBreaker(new HttpCircuitBreakerStrategyOptions
        {
            FailureRatio = 0.5,
            SamplingDuration = TimeSpan.FromSeconds(30),
            BreakDuration = TimeSpan.FromSeconds(15)
        });
        // No retry strategy: on timeout, query status by end-to-end ID instead
    });

19.3 PayTo Added

A digital payment agreement (mandate) that the customer authorises in their own banking app, so a business can pull payments over the NPP in real time.

• Use cases: subscriptions, utilities, insurance premiums, wallet top-ups, payroll and supplier runs, and "pay by bank" at online checkout.
• Migrating direct debits: a business can convert existing BECS direct debits into Migrated DDR Mandates without asking each customer to re-authorise. Banks' published terms require at least 30 days' notice, and the old BECS authority does not stop automatically.
• Status: PayTo began rolling out in mid-2022 and has grown since. It is a key building block for moving debits off BECS (19.4).

19.4 BECS / Direct Entry & batch payments Added

The Bulk Electronic Clearing System carries batch payments (payroll, welfare, direct debits) as fixed-width ABA files, exchanged and net-settled on business days. It is still Australia's largest retail payment system by value.

Every record is exactly 120 characters, separated by CRLF. Some banks also require a balancing (contra) record that debits the sender's own account.

The planned move away from BECS (public timeline)

• 2023: the industry announced it intended to decommission BECS, with June 2030 as the target.
• March 2025: the RBA published a risk assessment and asked for a shared vision, a roadmap and end-user input.
• December 2025: AusPayNet removed the June 2030 target date. No new date will be set until an agreed roadmap exists.
• 2025–26: an A2A Payments Roundtable (AusPayNet, AP+, RBA, Treasury) is shaping the future of account-to-account payments. It released a draft vision for consultation in April 2026. AP+ is developing NPP capabilities for very large bulk files.

In an interview, say "BECS is being wound down over time, but there is currently no fixed end date". Batch file skills will be needed for years.

// Check an ABA file's control totals before you send it
long credits = 0, debits = 0; int count = 0;
foreach (var line in File.ReadLines(path))
{
    if (line.Length != 120) throw new FormatException("Each ABA record must be 120 chars");
    switch (line[0])
    {
        case '1':                                        // detail record
            var cents = long.Parse(line.AsSpan(20, 10)); // positions 21-30
            if (line.Substring(18, 2) == "13") debits += cents;   // 13 = debit
            else credits += cents;                                 // 50-57 = credits
            count++;
            break;
        case '7':                                        // file total record
            if (long.Parse(line.AsSpan(30, 10)) != credits ||    // credit total
                long.Parse(line.AsSpan(40, 10)) != debits  ||    // debit total
                int.Parse(line.AsSpan(74, 6)) != count)          // record count
                throw new InvalidDataException("Control totals don't match");
            break;
    }
}

19.5 Cards: the four-party model Added

A card payment links cardholder → issuer and merchant → acquirer through a scheme. It happens in three steps: authorisation, clearing and settlement.

PCI DSS v4.x: shrink the scope

• PCI DSS v4.0.1 is the only active version (v4.0 retired 31 December 2024). The new "future-dated" v4 requirements became mandatory on 31 March 2025.
• Scope = every system that stores, processes or transmits card data, plus anything connected to it. Less scope = less audit, less risk.
• Ways to reduce it: hosted payment fields or redirect pages, tokenisation (network or PSP), point-to-point encryption terminals, network segmentation, and never logging the PAN.
• v4.x also tightens controls on scripts running on payment pages and on authentication (MFA into the cardholder data environment).

19.6 Cross-border payments & SWIFT ISO 20022 Added

International payments hop between banks that hold accounts with each other (correspondent banking), using Swift messages that are now ISO 20022 (CBPR+) for payment instructions.

• 22 November 2025: the MT/ISO 20022 coexistence period ended for cross-border payment instructions on Swift. Payment instructions must now be ISO 20022.
• Swift offers MT-to-ISO contingency conversion as a short-term last resort; it has been chargeable since January 2026.
• Statements and other non-instruction messages follow a later, phased roadmap. Swift is also mandating structured postal addresses; in August 2026 it extended that timeline, so check the latest dates.
• gpi: every payment carries a UETR (a unique end-to-end reference) so banks and customers can track it, including fees deducted along the way.
• Australia's HVCS started live ISO 20022 messaging in March 2023. Domestic MT/MX coexistence ended in September 2024.

19.7 Open Banking & the Consumer Data Right (CDR) Added

The CDR lets consumers tell their bank to share their data with an accredited data recipient, through standard, highly secured APIs, with consent they can withdraw at any time.

Architecture implications for a data holder

• API gateway with mTLS that trusts only the CDR certificate authority, plus rate limits and the CDR's performance and availability requirements.
• Authorisation server (FAPI-conformant): PAR, JARM, private key JWT, short-lived certificate-bound tokens, refresh tokens tied to the sharing period.
• Consent / arrangement store: the source of truth for what was shared and when it ends. Must support revocation from either side (the CDR arrangement revocation endpoint).
• Data quality: CDR APIs expose core-system data directly, so inconsistent data becomes a compliance issue.

builder.WebHost.ConfigureKestrel(k => k.ConfigureHttpsDefaults(
    https => https.ClientCertificateMode = ClientCertificateMode.RequireCertificate));

builder.Services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
    .AddJwtBearer(o =>
    {
        o.Authority = "https://auth.bank.example";
        o.Audience = "cdr-banking-api";
        o.MapInboundClaims = false;            // keep "cnf" as is
    });

// Sender-constrained token: the cert on this connection must match the token
app.MapGet("/banking/accounts", async (HttpContext ctx, ClaimsPrincipal user) =>
{
    var cert = await ctx.Connection.GetClientCertificateAsync();
    var cnf = user.FindFirst("cnf")?.Value;
    if (cert is null || cnf is null) return Results.Unauthorized();

    var expected = JsonDocument.Parse(cnf).RootElement.GetProperty("x5t#S256").GetString();
    var actual = Base64Url.EncodeToString(cert.GetCertHash(HashAlgorithmName.SHA256));
    return expected == actual ? Results.Ok(await LoadAccountsAsync(user)) : Results.Unauthorized();
}).RequireAuthorization();

19.8 Regulation & resilience for architects Added

Banking rules turn into concrete design requirements: tolerance levels become RTO/RPO, service-provider risk becomes exit plans, and AML becomes monitoring and record keeping.

19.9 Core banking & ledger basics Added

A ledger records every movement as balanced, immutable double entries. Balances are derived from them, and every posting must happen exactly once.

public readonly record struct Money(decimal Amount, string Currency)
{
    public Money Round() => this with { Amount = Math.Round(Amount, 2, MidpointRounding.ToEven) };
}

public async Task PostAsync(string idempotencyKey, Guid debitAcct, Guid creditAcct, Money amount)
{
    await using var tx = await db.Database.BeginTransactionAsync();
    var journal = new Journal { IdempotencyKey = idempotencyKey };   // unique index
    journal.Entries.Add(new Entry(debitAcct,  -amount.Amount, amount.Currency));
    journal.Entries.Add(new Entry(creditAcct, +amount.Amount, amount.Currency));
    db.Journals.Add(journal);

    var debit = await db.Accounts.SingleAsync(a => a.Id == debitAcct);
    debit.LedgerBalance -= amount.Amount;    // Account has a [Timestamp] row version
    var credit = await db.Accounts.SingleAsync(a => a.Id == creditAcct);
    credit.LedgerBalance += amount.Amount;

    try { await db.SaveChangesAsync(); await tx.CommitAsync(); }
    catch (DbUpdateException ex) when (IsUniqueViolation(ex)) { /* already posted: no-op */ }
}