DBA Banking Dictionary: Essential Terms Every Data Professional Should KnowManaging data in the banking sector requires a unique blend of database expertise, regulatory awareness, and domain-specific knowledge. This DBA Banking Dictionary compiles essential terms and concise explanations across database administration, financial concepts, security, compliance, and performance—aimed at data professionals working in banks, fintechs, or financial-services IT teams.
Database fundamentals
-
Database Management System (DBMS)
A software system that stores, retrieves, and manages data (examples: Oracle, Microsoft SQL Server, PostgreSQL, MySQL). In banking, DBMS choice affects reliability, compliance, and integration with core banking applications. -
Relational Database (RDBMS)
A DBMS that stores data in tables with rows and columns and enforces relationships via primary and foreign keys. Most core banking systems use relational databases for transactional integrity. -
ACID
Stands for Atomicity, Consistency, Isolation, Durability—the set of properties guaranteeing reliable transaction processing. ACID compliance is critical for financial transactions to prevent loss, duplication, or corruption. -
Schema
The structure defining tables, columns, data types, indexes, views, and constraints. Banking schemas often model accounts, customers, transactions, balances, and audit trails. -
Primary Key / Foreign Key
A primary key uniquely identifies a row in a table; a foreign key references a primary key in another table to maintain referential integrity. -
Index
A data structure that improves query performance. Index design in banking must balance read performance for reporting and write performance for high-volume transactional loads. -
Normalization / Denormalization
Normalization reduces redundancy by organizing data across related tables. Denormalization intentionally duplicates data for performance—often used in reporting layers or read-optimized replicas.
Transactions, concurrency and recovery
-
Transaction Log (WAL/Redo/Transaction Log)
A sequential record of all modifications. Used for crash recovery, point-in-time restores, and replication. Protecting the transaction log is essential for ensuring no transactions are lost. -
Checkpoint
A process that writes in-memory changes to disk to shorten recovery time. Checkpoint frequency and behavior can impact throughput and recovery objectives. -
Isolation Levels
Controls how concurrent transactions interact: Read Uncommitted, Read Committed, Repeatable Read, Serializable. Higher isolation prevents anomalies but reduces concurrency; banks often use Read Committed or Serializable depending on risk tolerance. -
Locking / Latches / MVCC
Mechanisms to manage concurrent access. Locking can cause contention; MVCC (Multi-Version Concurrency Control) provides snapshot reads to reduce blocking. -
Point-in-Time Recovery (PITR)
Restoring a database to a specific moment using backups plus transaction logs—vital for recovering from logical errors or data corruption.
Performance and scaling
-
Throughput / TPS (Transactions Per Second)
Measurement of transactional load. Banks track TPS for core systems (payments, card processing) and design capacity accordingly. -
Latency
Time taken to process a single operation. Low latency is crucial for user-facing banking services and payment systems. -
Sharding / Horizontal Partitioning
Distributing data across multiple nodes by shard key (e.g., customer ID) to scale write and storage capacity. Sharding adds complexity in cross-shard transactions and joins. -
Partitioning
Splitting a table into segments (range, list, hash) to improve manageability and query performance. Transactional tables (e.g., transactions) are often partitioned by date. -
Replication (Synchronous vs Asynchronous)
Copying data across instances for high availability and geographic distribution. Synchronous replication ensures no data loss but increases write latency; asynchronous reduces latency at the risk of lag. -
Caching
In-memory stores (e.g., Redis, Memcached) reduce DB load for frequently read data like account profiles or exchange rates. Must be designed to avoid stale or inconsistent reads for critical data.
Security and encryption
-
Encryption at Rest
Protecting stored data (disk, backups) using encryption to meet confidentiality requirements and regulatory standards. -
Encryption in Transit (TLS)
Securing network traffic between clients, application servers, and databases using TLS to prevent eavesdropping and tampering. -
Column-level / Field-level Encryption
Encrypting specific sensitive fields (e.g., PAN, SSN) so even DBAs without key access cannot read the data in plaintext. -
Key Management / HSM
Managing encryption keys securely, often using a Hardware Security Module (HSM) or centralized key manager to ensure separation of duties and auditability. -
Least Privilege / Role-Based Access Control (RBAC)
Granting users the minimum permissions needed. RBAC and fine-grained access control are essential for separation of duties and audit readiness. -
Auditing and Immutable Logs
Recording who accessed or changed data. Immutable audit logs help meet compliance and forensic requirements.
Data integrity, validation and lineage
-
Constraints (Check, Unique, Not Null)
Rules enforced by the DBMS to ensure data validity. Check constraints enforce business rules at the data layer (e.g., transaction amount >= 0). -
Data Validation
Multi-layered checks (application + database) to prevent invalid or fraudulent data from entering the system. -
Master Data Management (MDM)
Processes and systems that ensure consistent, accurate master records (customers, accounts) across systems. -
Data Lineage
Tracing how data flows and transforms across systems. Critical for regulatory reporting, investigations, and model validation. -
Referential Integrity
Ensuring relationships among tables remain consistent (no orphaned transactions without an account).
Backup, retention and disaster recovery
-
Full / Incremental / Differential Backups
Strategies to balance backup window, storage, and recovery time. Incremental and differential backups reduce storage but require careful restore sequencing. -
Recovery Point Objective (RPO) / Recovery Time Objective (RTO)
RPO: maximum acceptable data loss (time). RTO: maximum acceptable downtime. Banks set strict RPO/RTO for critical systems. -
Disaster Recovery (DR) Site
Secondary data center or cloud region configured to take over operations if the primary fails. DR runbooks and tested failovers are required in regulated environments. -
Retention Policy
Rules that define how long data and backups are kept to comply with regulations (e.g., transaction records retention).
Compliance and regulation-related terms
-
PCI DSS (Payment Card Industry Data Security Standard)
Standards for protecting cardholder data. DBAs must help ensure database configurations, access controls, and encryption meet PCI requirements when storing card data. -
GDPR / Data Subject Rights
European regulation requiring data protection and subject rights (access, deletion). Data professionals must ensure capability to locate, export, or delete a customer’s personal data. -
SOX (Sarbanes-Oxley)
U.S. regulation requiring controls over financial reporting systems, including change management and access controls for databases implicated in financial reporting. -
KYC / AML (Know Your Customer / Anti-Money Laundering)
Processes and systems that collect, validate, and monitor customer identity and transaction patterns for suspicious activity. Databases must support analytics, secure storage, and audit trails for KYC/AML workflows. -
Data Residency / Localization
Rules requiring data to be stored within specific geographic boundaries. Affects database architecture for multi-national banks.
Financial & banking domain terms DBAs should know
-
Ledger
The authoritative record of financial transactions. Core banking ledgers track debits/credits per account and are subject to strict integrity constraints. -
General Ledger (GL)
Aggregates transactions into accounts for accounting and financial reporting. DBAs supporting GL systems must preserve immutability and auditability. -
Settlement / Clearing
Processes that finalize payment obligations between parties and transfer funds. Databases used in settlement systems must guarantee transactional correctness and timing. -
Clearing House / ACH / SWIFT
Payment networks and messaging systems; data flows between internal DBs and external payment networks need strict validation, mapping, and secure transmission. -
Balance / Available Balance / Ledger Balance
Distinctions matter: ledger balance is the account’s balance at the last posted transactions; available balance reflects holds/pending transactions. DB schemas often model both. -
Reconciliation
Matching internal records with external statements or settlement reports to identify discrepancies. Reconciliation workflows depend on reliable identifiers, timestamps, and audit logs. -
Float
Time difference between transaction initiation and settlement that creates temporarily available funds. Float affects cash management reporting and interest calculations.
Observability and operational tooling
-
Monitoring / Metrics (CPU, I/O, Waits)
Tracking resource usage and database-specific metrics (e.g., buffer cache hit ratio, lock waits) to detect performance issues. -
Alerts / Runbooks
Predefined alerts and operational playbooks guide on-call DBAs through detection, triage, and remediation steps for common incidents. -
Query Profiling / EXPLAIN / Execution Plans
Tools to analyze how queries are executed and where bottlenecks exist. Query tuning and index adjustments rely on execution plan insights. -
Chaos Testing / Failure Injection
Controlled disruption to validate system resilience (e.g., network partitions, replica failures). Valuable for ensuring DR and HA behaviors.
Data architecture patterns
-
OLTP (Online Transaction Processing)
Systems optimized for many short transactional operations (banking core systems). Prioritize concurrency, durability, and low-latency writes. -
OLAP (Online Analytical Processing)
Systems optimized for complex read-heavy analytical queries (reporting, risk models). Often implemented in data warehouses or columnar stores. -
Lambda / Kappa Architectures
Patterns for combining batch and streaming data processing. Banks use these for real-time fraud detection (streaming) plus nightly reporting (batch). -
Data Lake / Data Warehouse
Centralized repositories: data lakes store raw, varied-format data; data warehouses store cleaned, structured data for reporting and analytics. -
Event Sourcing
Storing state changes as a sequence of events. Useful for auditability and reconstructing account histories, but requires careful storage and replay semantics.
Common data quality issues and controls
-
Duplicate Records
Causes: multiple ingestion paths, inconsistent deduplication keys. Controls: unique constraints, MDM, and deduplication jobs. -
Stale Data / Cache Inconsistency
Cached values diverging from source-of-truth. Controls: TTLs, cache invalidation strategies, and read-after-write guarantees where required. -
Skewed Data / Hot Partitions
Uneven distribution of load across shards or partitions leading to hotspots. Controls: better shard keys, adaptive partitioning, and request routing. -
Incorrect Timestamps / Timezone Handling
Timestamps must be stored in UTC with explicit timezone conversion at the presentation layer to avoid reconciliation errors.
Practical tips for DBAs in banking
- Automate backups, restores, and periodic recovery tests to validate DR procedures.
- Use least-privilege access controls and separate roles for DBAs, developers, and auditors.
- Partition large transactional tables by date and archive old partitions to manage storage and performance.
- Maintain a tamper-evident audit trail for sensitive operations and schema changes.
- Collaborate closely with application, security, and compliance teams—banking DB work is cross-functional.
- Keep a runbook for common incidents (replica lag, corrupt page, long-running queries) and rehearse failovers.
Quick-reference glossary (short form)
- ACID — Atomicity, Consistency, Isolation, Durability.
- RPO / RTO — Recovery Point Objective / Recovery Time Objective.
- PITR — Point-in-Time Recovery.
- WAL — Write-Ahead Log.
- MDM — Master Data Management.
- KYC / AML — Know Your Customer / Anti-Money Laundering.
- PCI DSS — Payment Card Industry Data Security Standard.
- GL — General Ledger.
- TPS — Transactions Per Second.
- MVCC — Multi-Version Concurrency Control.
If you want, I can: extract this into a one-page cheat sheet, generate a printable glossary PDF, or expand any section (e.g., index design for transaction-heavy tables, partitioning strategies, or encryption architecture).
Leave a Reply