Digital Wallets

A full dataset refresh processes every record in the wallet database on every sync cycle, regardless of how many records have actually changed. At a small scale, this is manageable. At enterprise scale, where a single sync cycle may involve millions of records, full refreshes consume processing time and infrastructure resources proportional to the total dataset size, not the volume of actual changes. Delta processing compares the incoming dataset against the current state, identifies the changed records, and processes only those. This keeps sync cycle duration and infrastructure cost proportional to activity volume, which is what makes the architecture sustainable as the wallet user base grows.

Database-level encryption protects the data store as a whole — if an attacker gains access at the database level, row-level encryption provides no additional protection. Row-level AES-256 encryption encrypts each record independently with its own key, so a database-level access event exposes only the records whose keys are also compromised. In a wallet context, where individual records correspond to individual user balances and transaction histories, row-level encryption limits the blast radius of a database compromise to the records specifically targeted rather than the full dataset.

The ingestion pipeline validates each file for integrity and completeness before initiating any processing. If validation fails — due to an incomplete transfer, a decryption error, or a schema mismatch — the pipeline halts at the ingestion stage and logs the failure with enough detail to identify whether the issue was at the transfer, decryption, or validation layer. No processing cycle runs against a file that has not passed validation, which prevents a partially transferred file from producing incorrect wallet states that then need to be identified and reversed.

Each encryption standard operates at a different layer and protects against a different attack surface. PGP encrypts the file at the point of transfer — protecting the data as it moves from the source system to the ingestion pipeline over SFTP. JWE (JSON Web Encryption, defined in RFC 7516) protects data as it moves between internal services — so inter-service communication within the platform is encrypted independently of the file transfer layer. AES-256 encrypts each record at the row level in storage — protecting data at rest independently of the transfer and inter-service layers. All three are needed because a compromise at any single layer should not expose data protected by the other two.

Polling requires downstream systems to query the wallet platform on a defined interval to check for state changes — introducing a latency ceiling equal to the polling interval, even when changes have already occurred. A webhook architecture inverts this: the wallet platform publishes an event to downstream systems at the moment a state change occurs. Systems that need to respond to balance updates or transaction completions receive the event immediately rather than waiting for their next polling cycle. This matters in financial applications where downstream systems — fraud detection, customer notifications, account management — need to respond to wallet events with minimal delay.

Node.js streams read and process the input file in chunks of a defined size rather than loading the full file into memory before processing begins. Each chunk is processed and released before the next is loaded, so memory usage remains proportional to the chunk size rather than the file size. This means a 10GB transaction batch file is processed with the same memory footprint as a 100MB file — only the processing duration differs. This is the property that makes stream processing the correct architectural choice for wallet batch operations at enterprise scale, where file sizes grow with the user base rather than remaining constant.

A full digital wallet platform — covering SFTP ingestion, PGP encryption, Node.js stream processing, delta sync logic, webhook architecture, and row-level AES-256 encryption — typically runs ten to sixteen weeks from architecture sign-off to production. The range depends on the volume of transaction data involved, the complexity of the source system's file format and transfer schedule, and the number of downstream systems receiving webhook events. We assess scope during the discovery phase before committing to a timeline.

The system is handed over production-ready, tested against representative batch sizes and transaction volumes, and documented at the service and API level. Your team can operate and extend it independently. We do not build on proprietary frameworks that require ongoing GeekyAnts involvement to run. If a formal support arrangement post-launch makes sense for your team, that is a separate conversation.