Skip to main content

Banking Roles & Teams

Overview

A bank is made up of many specialised teams. Understanding who does what helps you collaborate effectively, know who to escalate to, and understand where you fit in the payments ecosystem.

Three Lines of Defence Risk Governance & Agile Payment Pod Topology
SELECT LINE OF DEFENCE TO INSPECT:
1st Line: Business & Technology (Owns & Manages Risk)
Payments EngineeringPayments OperationsCore Banking TeamProduct Owners
2nd Line: Risk & Compliance (Independent Oversight & Rules)
Compliance & MLROFinancial Crime (AML/Sanctions)Operational RiskCyber Security (CISO)
3rd Line: Internal Audit (Independent Assurance)
Internal Audit TeamExternal Regulators (APRA, AUSTRAC, ASIC)
Governance & Regulatory Framework
1st Line: Business & Technology (Owns & Manages Risk)

Day-to-day risk ownership. Executes transactions, builds resilient systems, enforces inline automated validation controls, and manages payment exceptions.

Accountability & APRA CPS 230 Standard
Direct P&L and operational accountability. Must operate within risk appetite set by 2nd line.

Three Lines of Defence (3LoD Governance Framework)

Banks operate under the Three Lines of Defence (3LoD) risk governance framework โ€” mandated by global regulators (APRA CPS 220 / CPS 230 in Australia, Basel III globally). This model establishes clear boundaries between business execution, independent policy oversight, and objective audit assurance.

1st Line of Defence: Business & Operations (Risk Owners)

  • Who: Payments Engineering, Payments Operations, Core Banking, Retail/Corporate Business Units, Product Owners.
  • Responsibilities:
    • Own and manage operational, credit, and compliance risks day-to-day.
    • Implement automated inline controls within application code (e.g. duplicate payment checks, balance reservations, input validation).
    • Execute Business-As-Usual (BAU) payment processing, exception resolution, and initial incident response.
    • Establish Key Risk Indicators (KRIs) and operate within the Risk Appetite Statement (RAS) defined by 2nd Line.

2nd Line of Defence: Risk & Compliance (Independent Oversight & Policy)

  • Who: Compliance, Financial Crime (AML/CTF & Sanctions), Operational Risk, Cyber Security (CISO), Legal.
  • Responsibilities:
    • Set risk management frameworks, policies, and mandatory control standards.
    • Provide independent oversight and active challenge to 1st Line business decisions.
    • Review and approve production release risk assessments, new payment product launches, and sanctions screening threshold changes.
    • Has independent veto authority over production deployments or business operations that exceed risk appetite.
    • Direct reporting line to the Chief Risk Officer (CRO) and Board Risk Committee.

3rd Line of Defence: Internal Audit (Independent Assurance)

  • Who: Internal Audit Function, External Independent Auditors.
  • Responsibilities:
    • Provide independent, objective assurance on the design and operational effectiveness of 1st and 2nd Line controls.
    • Conduct periodic audits of payment engines, key management, HSM controls, and regulatory reporting accuracy (SMR/IFTI).
    • Direct, unfettered reporting line to the Board Audit Committee (completely independent of executive management).

Payments-Specific Teams

Payments Operations

The team responsible for the day-to-day running of payment processing:

Sub-teamResponsibilities
Payment ProcessingMonitor STP rates, handle exceptions
InvestigationsResolve unmatched payments, customer complaints
Nostro ReconciliationMatch correspondent account balances
SWIFT OperationsManage SWIFT connectivity, gpi tracking
Scheme OperationsManage NPP/BECS/RTGS submissions and monitoring

You'll work with Payments Ops when:

  • Your code produces payment exceptions (ops resolves them)
  • Building new exception management workflows
  • Investigating production incidents involving payments

Transaction Banking / Cash Management

Serves corporate and institutional clients:

RoleResponsibilities
Transaction BankerClient-facing; structures cash management solutions
Product Manager (Cash)Owns payment product (e.g., Osko for business)
Implementation ManagerOnboards corporates to host-to-host file delivery
Client ServicesHandles corporate client enquiries

Technology / Engineering

Within the technology division:

RoleFocus Area
Payments EngineerBuilds and maintains payment processing systems
Core Banking EngineerWorks on CBS (T24, Finacle, etc.)
Integration EngineerConnects channels, CBS, networks (APIs, MQ)
Data EngineerPayment data pipelines, reconciliation, reporting
Platform/SREReliability, uptime, incident response
Security EngineerEncryption, HSMs, API security
Test Engineer / QAEnd-to-end payment testing, regression

Product

RoleFocus
Product Owner (Payments)Backlog, user stories, prioritisation
Product ManagerStrategy, scheme submissions, roadmap
Business AnalystRequirements, process mapping, gap analysis

Compliance & Financial Crime

RoleResponsibilities
AML AnalystReviews transaction monitoring alerts
Sanctions AnalystReviews sanctions screening hits
Financial Crime InvestigatorDeep-dive fraud and AML investigations
Compliance ManagerPolicy ownership, regulatory change management
MLRO (Money Laundering Reporting Officer)Statutory role; signs off on SMR filings

Treasury

RoleResponsibilities
Treasury DealerFX trading, money market, liquidity management
Liquidity ManagerESA/nostro balance management, intraday liquidity
ALM (Asset/Liability Management)Balance sheet management
Treasury OperationsTrade confirmation, settlement instructions

Risk

RoleResponsibilities
Operational Risk ManagerIdentifies and monitors operational risks in payments
Market RiskFX and interest rate risk
Credit RiskCounterparty and customer credit exposure
Fraud Risk AnalystModels and rules for fraud detection

Escalation Paths in Payments

Know who to contact for common situations:

SituationWho to Contact
Payment stuck in processingPayments Operations
Sanctions alert on a paymentCompliance Analyst (2nd Line)
Fraud suspicion on a customerFraud team (1st Line)
NPP/BECS network outageScheme Operations + Technology
Corporate client complaintClient Services / Transaction Banking
Regulatory questionCompliance
Production system downOn-call engineer โ†’ Platform/SRE
Large financial loss eventOperational Risk + Senior Management
Media/public incidentCommunications + Risk

Key Acronyms Used in Banking Teams

AcronymFull FormContext
COOChief Operating OfficerHeads operations
CROChief Risk OfficerHeads risk function
CISOChief Information Security OfficerHeads cybersecurity
CTOChief Technology OfficerHeads technology
MLROMoney Laundering Reporting OfficerAML compliance
SMESubject Matter ExpertDomain expert on a topic
BAUBusiness As UsualDay-to-day operational work
SLAService Level AgreementTarget response/resolution times
RCARoot Cause AnalysisPost-incident investigation
P&LProfit and LossFinancial performance
RTB/CTBRun The Bank / Change The BankOps vs project/change work
MVPMinimum Viable ProductSmallest releasable feature
UATUser Acceptance TestingBusiness testing before go-live

Working in an Agile Payment Team (Engineering Pod Mechanics)

Payment engineering teams operate in multi-disciplinary Agile Pods designed for high reliability, strict compliance, and 24/7 mission-critical execution.

Pod Composition & Specialised Roles

  • Payment Tech Lead / Senior Engineers: Architects non-blocking event-driven microservices, guarantees idempotency keys, and enforces zero-downtime database migrations.
  • Product Owner (Payments): Translates scheme mandates (NPPA, SWIFT, AusPayNet) into prioritized epics and user stories.
  • Payments Operations SME: Embedded in pod to define real-time exception resolution flows, manual repair screens, and operational SLAs.
  • Compliance Champion (2nd Line Liaison): Embedded to review data privacy, audit logging, and AML/sanctions screening hook designs during sprint grooming.
  • QA & Synthetic Test Engineer: Builds automated ISO 20022 schema validation suites and executes synthetic payment simulation against scheme test harnesses.

Non-Functional Requirements (NFRs) in Payment Sprints

Unlike standard web apps, payment user stories must satisfy non-negotiable NFRs before passing Definition of Done (DoD):

  1. Sub-Second Latency: NPP payments must complete end-to-end processing in under 500ms.
  2. Strict Idempotency: System must safely absorb duplicate network retries without generating double-debits.
  3. 99.999% Availability: Zero planned downtime; deployments use Blue/Green or Canary strategies with automated rollback.
  4. Immutable Audit Trail: Every payment state change must emit structured audit events tagged with global trace IDs (UETR, EndToEndId).
  5. Dual-Control Release Approval: Production deployment requires independent sign-off from both 1st Line Tech Lead and 2nd Line Risk/Compliance.

๐Ÿ“–
Track Page Progress0 / 635 Read
Knowledge Base Completion0%