All projects

BCI · 2025 – 2026

Card Renewal & Management Platform

Senior Software Engineer

Expected to process 90,000 cards monthly once in production.

JavaSpring BootPostgreSQLKubernetesAzureJenkinsGroovy

The Problem

BCI needed to modernize its card renewal process for both debit and credit cards. Previously, the bank had no proactive system to detect cards approaching expiry, notify customers, or let them choose how to receive their new card. On top of that, the credit card domain had an unconstrained credit limit increase flow — users could request limit increases indefinitely, bypassing the bank’s own policies.

My Contribution

Card Renewal Platform

  • Built ms-renovaciontarjetasdebito-neg, the microservice responsible for querying customers’ expiring debit cards and scheduling their renewal. Users can choose their renewal method: pick up at a branch or home delivery.
  • Built ms-renovaciontarjetascredito-neg, the equivalent service for credit card renewals, including the data model for embossed card states (tarjetas_embozadas).
  • Integrated with job-logistica-tdd, a Jenkins-triggered cronjob that collects all scheduled renewals and inserts them into BCI’s logistics file system, initiating the physical card production and dispatch pipeline.

Credit Card Mobile Experience

  • Resolved a critical technical debt in ms-tarjetacredito-personasmobile-exp-andes: the credit limit increase endpoint had no guard on how many times a user could request an increase. I enforced the bank’s policy by introducing a puedeModificarCupo flag in the API response, giving the mobile client the signal to restrict or allow the action based on bank-defined rules.

Impact

The card renewal platform is in pre-production, with an expected throughput of 90,000 cards processed monthly once live — covering a significant portion of BCI’s active card portfolio. The credit limit enforcement fix directly closes a compliance gap that had been open in production.

Technical Challenges

The logistics integration required reliable, exactly-once delivery of card records into a file-based system — a notably unforgiving integration point. We designed the cronjob to be idempotent: re-runs after failures don’t create duplicate card entries in the logistics file. Coordinating the state machine between “card detected”, “renewal scheduled”, “user confirmed delivery preference”, and “inserted into logistics” across two microservices required careful event sequencing and rollback handling.