DEV Community: Peace Melodi

Three things I would tell any NestJS developer before they write their first banking fraud detection rule

Peace Melodi — Sun, 19 Jul 2026 17:20:02 +0000

The first fraud rule anyone writes usually looks harmless. A quick check on the transaction amount, maybe an if statement, done. Then a second rule gets added for new recipients. Then a third for transaction frequency. Within a few weeks, one method has quietly grown into a long chain of conditions, each one dependent on the ones before it, and nobody feels confident touching it anymore.

I have seen this exact pattern happen more than once, and it is worth talking through before it happens to you, because the fix is simple if you catch it early, and genuinely painful to unwind once it has spread across a real production system.

First, stop adding rules as more conditions in one function

The instinct when a new fraud rule is needed is almost always to open the existing validation method and add one more if statement.

validateTransaction(dto: CreateTransactionDto) {
  let score = 0;

  if (dto.amount > 10000) score += 100;
  if (this.isNewRecipient(dto.recipientId)) score += 35;
  // The next rule means editing this same method again

  return score;
}

This works for the first two or three rules. The trouble is that this single method is now responsible for every fraud rule the business will ever need, forever, and every new rule means going back into a function that keeps growing and getting harder to reason about safely. A mistake in one rule risks breaking every rule sitting beside it in the same block of code.

The better approach is giving every fraud rule its own isolated class, all following the same shared contract.

export interface FraudRule {
  readonly name: string;
  execute(transaction: CreateTransactionDto, history: any[]): number;
}

export class VelocityRule implements FraudRule {
  readonly name = 'Velocity Check';

  execute(transaction: CreateTransactionDto, history: any[]): number {
    const recentTransactions = history.filter(
      (tx) => tx.senderId === transaction.senderId,
    );

    return recentTransactions.length >= 3 ? 60 : 0;
  }
}

Each rule only knows about its own small piece of logic. A bug inside the velocity check cannot reach into or affect the rule checking transaction amounts, since they no longer share any code at all.

Second, keep the part that runs the rules completely generic

Once each rule is its own class, the temptation is still there to write a service that knows about each rule by name, calling one, then the next, then the next. That still means editing the core service every time a new rule is added, which defeats most of the benefit of separating them in the first place.

The fix is a service that simply loops through whatever rules exist, without needing to know anything about what any individual rule actually checks.

@Injectable()
export class TransactionsService {
  private readonly transactionHistory: any[] = [];

  private readonly rules: FraudRule[] = [
    new HighAmountRule(),
    new NewRecipientRule(),
    new VelocityRule(),
  ];

  validateTransaction(dto: CreateTransactionDto) {
    let totalScore = 0;
    const flaggedBy: string[] = [];

    for (const rule of this.rules) {
      const score = rule.execute(dto, this.transactionHistory);
      if (score > 0) {
        totalScore += score;
        flaggedBy.push(rule.name);
      }
    }

    const action =
      totalScore >= 70 ? 'blocked' : totalScore >= 35 ? 'review' : 'allowed';

    return { totalScore, action, flaggedBy };
  }
}

Adding a new fraud rule from this point on means writing a new class and dropping it into that array. The loop itself never changes, no matter how many rules eventually exist. This is the practical benefit of keeping the engine open to new rules without ever needing to modify how it actually runs them.

Third, test each rule completely on its own

The last mistake I would warn against is testing fraud detection the same way the old tangled function was written, one enormous test that sets up a complicated transaction and checks the final combined score. That kind of test tells you something failed, but not which rule caused it, or why.

Since every rule is now its own small class with one clear job, each one can be tested in complete isolation.

describe('VelocityRule', () => {
  it('flags a sender with three or more recent transactions', () => {
    const rule = new VelocityRule();
    const history = [
      { senderId: 'user1' },
      { senderId: 'user1' },
      { senderId: 'user1' },
    ];

    const score = rule.execute({ senderId: 'user1' } as any, history);

    expect(score).toBe(60);
  });

  it('does not flag a sender with fewer than three recent transactions', () => {
    const rule = new VelocityRule();
    const history = [{ senderId: 'user1' }];

    const score = rule.execute({ senderId: 'user1' } as any, history);

    expect(score).toBe(0);
  });
});

A test like this needs no elaborate setup and checks exactly one thing. Multiply that across every rule in the system, and the whole fraud engine becomes something a team can trust, verify, and extend with confidence, rather than something everyone is quietly afraid to touch.

For anyone who wants to see this exact pattern applied in a working example rather than just isolated snippets, here is a small fraud detection engine built around it.

PeaceMelodi / aegis-fraud-core

A high throughput, modular risk scoring engine built with NestJS. Utilizes the Strategy Pattern to execute completely decoupled financial threat analysis metrics and evaluation pipelines in real time.

Aegis Fraud Core

A high throughput, modular transaction risk scoring engine designed for real time threat mitigation.

NestJS Framework •
TypeScript Core •
Strategy Pattern Architecture •
Strict Payload Validation

Architectural Highlights •
Directory Layout •
Getting Started •
API Specification

Architectural Highlights

Aegis Fraud Core decouples complex evaluation logic from execution pipelines to maintain an extensible, production-grade security architecture.

Strategy Pattern

Risk calculations are isolated into self-contained strategy classes adhering to a strict interface contract. The engine loops through rules uniformly without tight coupling.

Front-Door Interception

Enforces strict payload shape and structural integrity right at the HTTP layer using global pipes. Malformed data is dropped before reaching core logic.

Contextual Analytics

Tracks multi-transaction profiles via low-latency state tracking to intercept distributed behavioral threat vectors, such as velocity attacks.

Directory Layout

Click to expand file tree

src/
├── main.ts                       # Entry point binding global validation pipes
├── app.module.ts
└── transactions/

…

View on GitHub

The bigger picture

None of these three things require anything exotic, a shared interface, a generic loop, and small isolated tests. What they prevent is the slow, quiet decay that turns fraud detection into the one file nobody wants to open. NestJS makes this structure genuinely easy to set up from the start, since dependency injection and clean module boundaries are already built around keeping responsibilities separate rather than tangled together.

Fraud rules change constantly in any real fintech system, new patterns get discovered, thresholds shift, entirely new checks get added months later. A system built this way absorbs that change one small file at a time, instead of one increasingly fragile function trying to hold everything at once.

If your team is building fraud detection or any rules based decision logic and wants it structured to actually survive years of changes rather than just the first few weeks, that is exactly the kind of problem I would be glad to help with.

I am Peace Melodi, a backend software engineer. If you want your business to scale big, comfortably handling millions of users without breaking, with strong scalability and security in place, feel free to reach out.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368

PeaceMelodi / PeaceMelodi

Hi My name is Peace Melodi

Backend Software Engineer

Backend Software Engineer. Building secure, scalable and well architected server systems.

I specialize in building scalable backend systems and modern fullstack web applications. I love turning ideas into real, deployed, working products.

🖥️ See my portfolio at MyPortfolio
✉️ You can contact me at peacemelodi1@gmail.com

View on GitHub

Four things I would check first with NestJS if a bank's API kept leaking sensitive data

Peace Melodi — Fri, 17 Jul 2026 23:10:07 +0000

A bank's API rarely leaks sensitive data on purpose. Nobody writes a line of code that says send the customer's full account number to anyone who asks. It happens in smaller, quieter ways, a response object that includes more fields than the frontend actually needed, an authorization check that confirms someone is logged in but never checks whether they should see this specific record, a log line that was only meant for debugging but ended up storing a full card number in plain text.

If I were brought in to look at a bank or fintech API that had a data exposure problem, these are the four places I would check first, in the order I would check them.

First, what the response actually sends back, not what the code assumes it sends

The most common leak I see is not a security bug in the traditional sense, it is an entity object being returned directly from the database without shaping what actually leaves the server.

@Entity()
export class Customer {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  fullName: string;

  @Column()
  nationalIdNumber: string;

  @Column()
  passwordHash: string;
}

@Controller('customers')
export class CustomersController {
  @Get(':id')
  async getCustomer(@Param('id') id: string) {
    return this.customerService.findById(id);
  }
}

Whatever fields exist on that entity get sent to the client, including a national id number and a password hash that the frontend never needed and should never have been able to see. The fix is controlling the shape of the response explicitly, rather than trusting that nobody will notice the extra fields.

export class CustomerResponseDto {
  id: string;
  fullName: string;

  @Exclude()
  nationalIdNumber: string;

  @Exclude()
  passwordHash: string;
}

@Controller('customers')
@UseInterceptors(ClassSerializerInterceptor)
export class CustomersController {
  @Get(':id')
  async getCustomer(@Param('id') id: string): Promise<CustomerResponseDto> {
    const customer = await this.customerService.findById(id);
    return plainToInstance(CustomerResponseDto, customer);
  }
}

With the serializer interceptor in place, excluded fields never make it into the response, no matter what the underlying entity contains, and no matter what gets added to that entity later by someone who forgets this rule exists.

Second, whether the requester should see this specific record, not just whether they are logged in

Being authenticated answers one question, who is this person. It does not answer a second, completely separate question, should this specific person see this specific record. A shockingly common bug in financial APIs is a route that checks for a valid token, then happily returns any account by id, regardless of whether it belongs to the person asking.

@Injectable()
export class AccountOwnershipGuard implements CanActivate {
  constructor(private readonly accountsService: AccountsService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const requestedAccountId = request.params.id;
    const requestingUserId = request.user.id;

    const account = await this.accountsService.findById(requestedAccountId);

    if (!account || account.ownerId !== requestingUserId) {
      throw new ForbiddenException('You do not have access to this account');
    }

    return true;
  }
}

This guard sits alongside authentication, not instead of it, and closes the gap between someone being a valid user and someone being the right user for this particular piece of data.

Third, what actually ends up in the logs

Logging is where I have seen sensitive data leak in ways nobody intended and almost nobody notices, since logs are rarely reviewed with the same scrutiny as an API response. A request or error logger that dumps the full request body during debugging can quietly store card numbers, national id numbers, or full addresses in plain text log files for months.

@Injectable()
export class RedactingLoggerInterceptor implements NestInterceptor {
  private readonly sensitiveFields = ['cardNumber', 'nationalIdNumber', 'password'];

  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const request = context.switchToHttp().getRequest();
    const redactedBody = { ...request.body };

    for (const field of this.sensitiveFields) {
      if (redactedBody[field]) {
        redactedBody[field] = '[redacted]';
      }
    }

    Logger.log(`Incoming request: ${JSON.stringify(redactedBody)}`);

    return next.handle();
  }
}

Redacting known sensitive fields before anything gets written to a log means a debugging session six months from now never accidentally becomes the reason a customer's data ended up somewhere it should not be.

Fourth, whether the API can be scraped one record at a time

The last thing I would check is not a single leaked field, it is whether the API allows someone to quietly pull large amounts of data by simply guessing or iterating through ids, one request at a time, faster than any human would ever do it manually.

@Controller('accounts')
@UseGuards(ThrottlerGuard)
@Throttle({ default: { limit: 20, ttl: 60000 } })
export class AccountsController {
  @Get(':id')
  @UseGuards(AccountOwnershipGuard)
  async getAccount(@Param('id') id: string) {
    return this.accountsService.findById(id);
  }
}

Combined with the ownership guard from earlier, this limits how many requests a single client can make in a given window, which makes large scale scraping meaningfully slower and easier to notice, even in the rare case where an authorization check elsewhere has a gap.

The bigger picture

None of these four checks are exotic. Controlling exactly what a response contains, confirming ownership and not just identity, keeping sensitive fields out of logs, and limiting how fast an API can be queried, these are all things NestJS makes genuinely straightforward through interceptors, guards, and built in throttling. The hard part is rarely the tooling, it is remembering to apply these checks consistently across every endpoint that touches sensitive data, not just the ones that feel obviously risky.

If your team is building or maintaining an API that handles financial or personal data and wants a second set of eyes checking for exactly these kinds of gaps, that is exactly the kind of review I would be glad to help with.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

A founder once asked me why refunds kept disappearing, here is what NestJS was actually doing

Peace Melodi — Fri, 17 Jul 2026 22:48:01 +0000

A founder once messaged me with a problem that sounded almost too simple to be real. Customers were saying they never received their refund. Support would check the payment provider's dashboard, see the refund clearly marked as processed, and tell the customer it was sent. The customer would insist it never showed up. Both sides were technically right, and that is exactly what made it so hard to track down.

The refund had genuinely gone through on the provider's side. What had not happened was anything on the backend's side. The internal record still showed the original payment as final, no refund entry existed anywhere in the ledger, and no email had gone out to tell the customer anything had changed. The money moved, but the system never found out.

Where this actually breaks

The refund flow looked simple on paper, call the provider's refund endpoint, and if it succeeds, mark the transaction as refunded.

@Injectable()
export class RefundsService {
  constructor(
    private readonly providerClient: PaymentProviderClient,
    private readonly transactionRepo: Repository<Transaction>,
  ) {}

  async processRefund(transactionId: string, amount: number) {
    const result = await this.providerClient.refund(transactionId, amount);

    const transaction = await this.transactionRepo.findOne({
      where: { id: transactionId },
    });
    transaction.status = 'refunded';
    await this.transactionRepo.save(transaction);

    return result;
  }
}

This code assumes the call to the provider and the update to the internal database always both succeed together. In reality, the refund call to the provider can succeed while the very next line, updating the local database, fails or never runs at all, because the server restarted, the request timed out on the way back, or an unrelated error interrupted the function before it finished. From the provider's point of view, the refund is done. From your own system's point of view, nothing happened.

Treating a refund like its own event, not a status flip

The first real fix was similar to something I have run into with payments generally, stop treating a refund as simply flipping a status on the original transaction, and instead record it as its own event with its own history.

@Entity()
export class RefundEvent {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  transactionId: string;

  @Column()
  amount: number;

  @Column()
  providerRefundId: string;

  @Column({ default: 'initiated' })
  status: string;

  @CreateDateColumn()
  createdAt: Date;
}

This gives the refund its own identity from the moment it starts, before the provider has even confirmed anything, so there is always a record that a refund was attempted, even if a later step fails.

Making the refund resilient to a crash in the middle

With the refund now recorded as its own row, the actual processing step can be structured so that a crash between the provider call and the internal update does not leave things silently inconsistent.

@Injectable()
export class RefundsService {
  constructor(
    private readonly providerClient: PaymentProviderClient,
    private readonly refundRepo: Repository<RefundEvent>,
    @InjectQueue('refund-notifications') private readonly notifyQueue: Queue,
  ) {}

  async processRefund(transactionId: string, amount: number) {
    const refund = await this.refundRepo.save({
      transactionId,
      amount,
      status: 'initiated',
      providerRefundId: '',
    });

    const providerResult = await this.providerClient.refund(transactionId, amount);

    refund.providerRefundId = providerResult.id;
    refund.status = 'confirmed';
    await this.refundRepo.save(refund);

    await this.notifyQueue.add('refund-confirmed', {
      transactionId,
      amount,
    });

    return refund;
  }
}

The row exists as initiated before the provider is even called, so if the process dies right after the provider confirms but before the local update finishes, there is still a clear record that a refund was in progress and needs to be checked, rather than nothing at all.

Catching the ones that got stuck in the middle

Recording the refund as its own event also makes it possible to find and fix the exact case that started this whole problem, refunds that succeeded with the provider but never finished updating locally. A scheduled job can look for anything stuck in the initiated state for longer than it should reasonably take.

@Injectable()
export class StuckRefundsChecker {
  constructor(
    private readonly refundRepo: Repository<RefundEvent>,
    private readonly providerClient: PaymentProviderClient,
  ) {}

  @Cron('*/15 * * * *')
  async checkStuckRefunds() {
    const stuck = await this.refundRepo.find({
      where: { status: 'initiated' },
    });

    for (const refund of stuck) {
      const providerStatus = await this.providerClient.getRefundStatus(
        refund.transactionId,
      );

      if (providerStatus.completed) {
        refund.status = 'confirmed';
        await this.refundRepo.save(refund);
      }
    }
  }
}

This job runs every fifteen minutes, quietly closing the gap between what the provider actually did and what the internal system knows about, without needing a customer to complain first before anyone finds out.

The bigger picture

Nothing about this problem was caused by bad code in the traditional sense. Every individual line worked exactly as written. The issue was assuming two separate operations, an external call and a local update, would always succeed or fail together, when nothing in a distributed system actually guarantees that. Once refunds were treated as their own tracked event instead of a simple status flip, both the crash resilience and the ability to catch anything that slipped through became straightforward to build with NestJS's queues and scheduled jobs.

The founder's original question was simple, why do refunds keep disappearing, but the honest answer was that they were never disappearing, they were just never fully arriving in the first place.

If your team has ever had a similar gap between what your payment provider says happened and what your own system actually recorded, that is exactly the kind of problem worth catching early.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

I reviewed a NestJS fintech backend where the numbers never quite matched, this is the fix

Peace Melodi — Fri, 17 Jul 2026 22:10:47 +0000

I was asked to look at a fintech backend where something small but persistent kept happening. Every month when the finance team tried to close the books, the internal ledger and the payment processor's own records were off by a small amount. Not a dramatic amount, sometimes a few transactions, sometimes a few dollars here and there, but enough that nobody could confidently say the numbers were correct. And in a fintech, correct is not optional.

This is called reconciliation drift, and it is one of the quieter problems a payments backend can have. It does not throw an error. It does not crash anything. It just slowly stops being trustworthy, one small mismatch at a time, until someone finally notices during a monthly close and has to spend hours figuring out where things went wrong.

What was actually happening

Once I started digging, the cause was not one single bug. It was a pattern that shows up a lot in systems that grow organically over time, multiple different places in the code were allowed to change a transaction's status or a balance, and none of them were talking to each other.

A webhook handler updated a transaction when the payment provider confirmed it. A retry job also updated the same transaction if the original webhook was ever missed. And an admin tool, built later for handling support tickets, allowed a staff member to manually mark a transaction as settled if a customer complained. Three different code paths, three different points where the same number could be changed, and no single place that recorded why a change happened or which of these three paths actually caused it.

@Injectable()
export class TransactionsService {
  async markSettled(transactionId: string) {
    const transaction = await this.transactionRepo.findOne({
      where: { id: transactionId },
    });

    transaction.status = 'settled';
    await this.transactionRepo.save(transaction);
  }
}

This method looked fine everywhere it was called. The problem was that it was called from three different places, and the transaction record itself kept no history of that. Once a transaction was marked settled, there was no way to tell whether it had happened once, correctly, or twice, incorrectly.

The fix, treat every change as an event, not an overwrite

The real fix was not patching each of those three code paths individually. It was changing how transactions record their own history in the first place. Instead of updating a transaction's status directly, every change becomes its own recorded entry, and the transaction's current state is something you calculate from that history, not something you overwrite.

@Entity()
export class TransactionEvent {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  transactionId: string;

  @Column()
  eventType: string;

  @Column()
  source: string;

  @CreateDateColumn()
  createdAt: Date;
}

@Injectable()
export class TransactionsService {
  constructor(
    private readonly eventRepo: Repository<TransactionEvent>,
  ) {}

  async recordSettlement(transactionId: string, source: string) {
    await this.eventRepo.save({
      transactionId,
      eventType: 'settled',
      source,
    });
  }

  async getCurrentStatus(transactionId: string): Promise<string> {
    const events = await this.eventRepo.find({
      where: { transactionId },
      order: { createdAt: 'ASC' },
    });

    const latest = events[events.length - 1];
    return latest ? latest.eventType : 'pending';
  }
}

The source field is what makes debugging this kind of issue possible going forward. Once every change records where it came from, the webhook, the retry job, or the admin tool, you can immediately see if the same transaction was settled twice by two different paths, instead of just seeing a status that quietly changed with no explanation attached.

The fix, an automated job that actually compares your records against theirs

Recording history properly stops new mistakes from being invisible, but it does not catch drift that already exists, or drift caused by something entirely outside your own system, like a webhook that never arrived at all. For that, the backend needs to actively compare its own records against the payment provider's records on a regular schedule, rather than assuming they always agree.

NestJS's schedule module makes this straightforward to set up as a recurring job.

@Injectable()
export class ReconciliationService {
  constructor(
    private readonly transactionRepo: Repository<TransactionEvent>,
    private readonly discrepancyRepo: Repository<ReconciliationDiscrepancy>,
    private readonly providerClient: PaymentProviderClient,
  ) {}

  @Cron('0 2 * * *')
  async runDailyReconciliation() {
    const providerRecords = await this.providerClient.getSettledTransactions();
    const internalStatuses = await this.getAllInternalStatuses();

    for (const record of providerRecords) {
      const internalStatus = internalStatuses.get(record.transactionId);

      if (internalStatus !== 'settled') {
        await this.discrepancyRepo.save({
          transactionId: record.transactionId,
          issue: 'provider shows settled but internal record does not',
        });
      }
    }
  }
}

This job runs quietly every night, comparing what the provider says actually happened against what your own system believes happened. Anything that does not line up gets written down as a discrepancy, rather than staying hidden until someone stumbles onto it during a manual review weeks later.

@Entity()
export class ReconciliationDiscrepancy {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  transactionId: string;

  @Column()
  issue: string;

  @Column({ default: false })
  resolved: boolean;

  @CreateDateColumn()
  detectedAt: Date;
}

Keeping discrepancies in their own table, separate from transactions themselves, means the finance team has a single place to look every morning, a short list of exactly what needs attention, instead of having to compare two entire data sets by hand.

Making the discrepancies actually get noticed

A table full of unresolved mismatches is only useful if someone actually sees it. Once the discrepancy records existed, the next step was making sure the job did not just write quietly to a database that nobody checked.

@Injectable()
export class ReconciliationService {
  constructor(
    private readonly notificationService: NotificationService,
  ) {}

  private async notifyIfDiscrepanciesFound(count: number) {
    if (count > 0) {
      await this.notificationService.alertFinanceTeam(
        `Reconciliation found ${count} unresolved mismatches overnight`,
      );
    }
  }
}

This is a small addition, but it is the difference between a system that quietly protects itself and one that quietly accumulates a growing pile of unresolved discrepancies nobody remembers to check.

The bigger picture

None of this required exotic tooling. A recorded event history instead of silent overwrites, a scheduled job that compares your truth against the provider's truth, and a clear place for discrepancies to land where someone will actually see them. NestJS made this easy to structure cleanly, a dedicated service for events, a dedicated service for reconciliation, and a built in scheduler that made the recurring job simple to wire up without reaching for a separate tool.

What this kind of review usually reveals is not one dramatic bug. It is a handful of small, reasonable seeming decisions made at different points in time, each one fine on its own, that quietly stopped agreeing with each other. Catching that early is a lot cheaper than discovering it during an audit.

If your team suspects your own numbers might not fully line up with what your payment provider believes happened, that gap is worth closing before it grows, and it is exactly the kind of review I would be glad to help with.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

If a bank hired me to fix their webhook handling, here is how NestJS would help me start

Peace Melodi — Thu, 16 Jul 2026 17:02:04 +0000

A bank or payment provider sends a webhook the moment something happens. A transfer completes, a payment settles, a dispute is opened. The backend receiving that webhook is supposed to update its records and move on. Simple in theory.

In practice, the same webhook often arrives more than once. The provider's server times out waiting for a response, assumes the delivery failed, and sends it again. Now the backend has processed the same event twice. If that event triggered sending a confirmation email, the customer gets two emails. If it triggered releasing funds or updating an account balance, that is a much bigger problem, and the kind of bug that does not show up in testing, only under real load with real retries.

If I walked into a bank or fintech company and found this happening, this is exactly how I would think through fixing it using NestJS.

Why this keeps happening

Most payment providers, from Stripe to Worldpay to bank transfer rails, use what is called at least once delivery. They do not promise to send an event exactly once. They promise to keep retrying until they get a successful response. This means duplicates are not a bug on their end, they are expected behavior on your end that has to be handled.

The mistake I see most often is a webhook handler that assumes every request it receives is a brand new event.

@Controller('webhooks')
export class WebhooksController {
  constructor(private readonly transactionsService: TransactionsService) {}

  @Post('payment-provider')
  async handleWebhook(@Body() payload: PaymentWebhookDto) {
    await this.transactionsService.markSettled(payload.transactionId);
    return { received: true };
  }
}

This works the first time an event arrives. It quietly breaks the moment that same event arrives a second time, because nothing here checks whether it has already been processed.

Verifying the webhook actually came from the provider

Before anything else, I would make sure the request is genuine. Anyone can send a POST request to a public endpoint. Providers sign their webhook payloads with a shared secret, usually using HMAC, and expect you to verify that signature before trusting anything in the body.

@Injectable()
export class WebhookSignatureGuard implements CanActivate {
  constructor(private readonly configService: ConfigService) {}

  canActivate(context: ExecutionContext): boolean {
    const request = context.switchToHttp().getRequest();
    const signature = request.headers['x-provider-signature'];
    const secret = this.configService.get('WEBHOOK_SECRET');

    const expectedSignature = crypto
      .createHmac('sha256', secret)
      .update(JSON.stringify(request.body))
      .digest('hex');

    if (signature !== expectedSignature) {
      throw new UnauthorizedException('Invalid webhook signature');
    }

    return true;
  }
}

This becomes a guard sitting in front of the webhook route, so nothing unverified even reaches the handler.

Making the handler safe to run more than once

Once the request is verified, the next step is deduplication. Every well designed webhook includes a unique event ID that stays the same across retries. I would store that ID the first time it is seen, and skip processing entirely if it shows up again.

@Controller('webhooks')
@UseGuards(WebhookSignatureGuard)
export class WebhooksController {
  constructor(
    private readonly webhookEventsService: WebhookEventsService,
    @InjectQueue('webhook-processing') private readonly webhookQueue: Queue,
  ) {}

  @Post('payment-provider')
  async handleWebhook(@Body() payload: PaymentWebhookDto) {
    const alreadySeen = await this.webhookEventsService.exists(payload.eventId);

    if (alreadySeen) {
      return { received: true };
    }

    await this.webhookEventsService.recordEvent(payload.eventId);
    await this.webhookQueue.add('process', payload);

    return { received: true };
  }
}

Notice that the response is returned quickly, right after the event is recorded and queued, not after the full processing is done. Providers expect a fast response, usually within a few seconds. If your handler takes too long doing the actual work before responding, the provider assumes failure and retries an event that already succeeded, which brings you right back to duplicates. Acknowledging quickly and processing separately avoids that trap entirely.

The recordEvent call should rely on a unique constraint at the database level, not just an application level check, since two identical webhook deliveries can arrive close enough together that a simple check and insert has a race condition.

@Entity()
export class WebhookEvent {
  @PrimaryColumn()
  eventId: string;

  @CreateDateColumn()
  receivedAt: Date;
}

With eventId as the primary column, a second insert attempt for the same event fails at the database level, which is a much safer guarantee than checking first and inserting second.

Doing the actual work in the background

The queue processor is where the real update happens, completely separate from the request that came in from the provider.

@Processor('webhook-processing')
export class WebhookProcessor {
  constructor(private readonly transactionsService: TransactionsService) {}

  @Process('process')
  async handleWebhookEvent(job: Job<PaymentWebhookDto>) {
    const { transactionId, status } = job.data;

    if (status === 'settled') {
      await this.transactionsService.markSettled(transactionId);
    }

    if (status === 'failed') {
      await this.transactionsService.markFailed(transactionId);
    }
  }
}

If this step fails for any reason, BullMQ retry settings handle trying again, without the provider needing to resend anything or the bank facing a repeated webhook storm.

The bigger picture

NestJS will not stop a payment provider from retrying webhooks, and it should not try to. Retries are the provider protecting itself against uncertainty. What NestJS gives you is a clean place to put each responsibility, a guard for verifying the request is genuine, a service for tracking what has already been seen, and a queue for doing the actual work safely away from the response cycle. None of these pieces are complicated on their own. What matters is that the structure makes it hard to skip any of them by accident, which is usually how these bugs get into production in the first place.

If your team is dealing with webhook reliability issues, duplicate processing, or anything similar around payment events, I would be glad to talk through how to restructure it.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

Here is how I would use NestJS to stop one fraud check from freezing an entire fintech platform

Peace Melodi — Thu, 16 Jul 2026 16:41:37 +0000

Picture this. A fintech company processes thousands of transactions a day. Every single one of them has to pass through a fraud check before it goes through. That check calls out to a third party service, or runs some scoring logic that takes a second or two to complete. On a normal day, nobody notices.

Then a busy period hits. Maybe it is a payday, maybe it is a sale, maybe it is just an unusually active morning. Suddenly that same fraud check, the one that took a second or two, starts taking five seconds, then ten. Requests start queueing up behind it. New transactions cannot even get a response back. Support tickets start coming in. Someone on the team eventually says the dreaded sentence, the whole platform is down, and the actual cause is one check that was never supposed to be a bottleneck in the first place.

I have seen this pattern more than once, and it almost always comes from the same root cause. A fraud check, or any external dependency like it, was built to sit directly inside the request response cycle. If I walked into a fintech company and saw this happening, this is exactly how I would think through fixing it using NestJS.

What is actually happening under the hood

The problem usually looks something like this in code. A transaction comes in, and before anything else happens, the controller calls the fraud service and waits for a response before doing anything further.

@Controller('transactions')
export class TransactionsController {
  constructor(private readonly fraudService: FraudService) {}

  @Post()
  async createTransaction(@Body() dto: CreateTransactionDto) {
    const fraudResult = await this.fraudService.checkTransaction(dto);

    if (fraudResult.riskLevel === 'high') {
      throw new BadRequestException('Transaction flagged as high risk');
    }

    return this.transactionsService.process(dto);
  }
}

This looks reasonable at first glance. It even works fine at low traffic. The issue is that every open request is now sitting there waiting on a network call to a service you do not fully control. If that fraud provider slows down even slightly, every request behind it slows down too, and NestJS, like any Node based framework, only has so many resources to keep threads and connections open while everyone waits.

The fix is not to make the fraud check faster. Sometimes you cannot control that. The fix is to stop putting it directly in the critical path of every transaction.

Moving the fraud check off the main request path

Instead of calling the fraud service and blocking the response, I would accept the transaction immediately, mark it as pending review, and hand the actual fraud check off to a background queue. NestJS has solid support for this through its queue integration, commonly paired with BullMQ and Redis.

Here is what the controller looks like once the fraud check is no longer sitting in the request path.

@Controller('transactions')
export class TransactionsController {
  constructor(
    private readonly transactionsService: TransactionsService,
    @InjectQueue('fraud-check') private readonly fraudQueue: Queue,
  ) {}

  @Post()
  async createTransaction(@Body() dto: CreateTransactionDto) {
    const transaction = await this.transactionsService.createPending(dto);

    await this.fraudQueue.add('check', {
      transactionId: transaction.id,
      payload: dto,
    });

    return {
      transactionId: transaction.id,
      status: 'pending_review',
    };
  }
}

The response now comes back almost instantly, no matter how slow the fraud provider is having a bad day. The transaction sits in a pending state, and the fraud check happens separately.

Processing the fraud check in the background

The actual fraud check now runs inside a processor that consumes jobs from that queue. This is where the slow, unpredictable work happens, completely away from the main request thread.

@Processor('fraud-check')
export class FraudCheckProcessor {
  constructor(
    private readonly fraudService: FraudService,
    private readonly transactionsService: TransactionsService,
  ) {}

  @Process('check')
  async handleFraudCheck(job: Job<{ transactionId: string; payload: any }>) {
    const { transactionId, payload } = job.data;

    const result = await this.fraudService.checkTransaction(payload);

    if (result.riskLevel === 'high') {
      await this.transactionsService.markFlagged(transactionId);
    } else {
      await this.transactionsService.markApproved(transactionId);
    }
  }
}

If the fraud provider is slow, only this background worker feels it. Requests coming into the platform keep flowing normally. If the provider goes down entirely, BullMQ retry settings let you retry the job a set number of times with a backoff period instead of the whole platform grinding to a halt.

Letting the client know once a decision is made

Since the response is no longer available at the time of the fraud decision, the client needs another way to find out what happened. Depending on what the platform already supports, this is usually done with a webhook, a websocket event, or a status endpoint the client can check.

A simple status endpoint looks like this.

@Controller('transactions')
export class TransactionsStatusController {
  constructor(private readonly transactionsService: TransactionsService) {}

  @Get(':id/status')
  async getStatus(@Param('id') id: string) {
    const transaction = await this.transactionsService.findById(id);
    return {
      transactionId: transaction.id,
      status: transaction.status,
    };
  }
}

For platforms that want something more immediate, NestJS also supports WebSockets through gateways, so the client can be pushed a status update the moment the background job finishes, instead of having to poll for it.

Why this matters beyond just fraud checks

The specific problem here was a fraud check, but the same pattern applies to anything slow or unreliable sitting inside a request. Credit checks, KYC verification calls, external scoring services, anything that depends on a third party over the network is a candidate for this same treatment. The moment one of these calls can be slow, the request handling it should not be the one waiting around for it.

The bigger picture

NestJS does not make fraud detection smarter, and it will not fix a slow third party provider on its own. What it gives you is a clean, structured way to separate what needs an instant response from what can safely happen in the background. Queues, processors, and gateways are built in as first class citizens, not something you have to bolt on awkwardly. That structure is what lets a team keep a platform responsive even when the systems it depends on are having a rough day.

If your team is dealing with a similar bottleneck, whether it is fraud checks, KYC calls, or any slow dependency sitting where it should not be, I would be glad to talk through how to restructure it.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

What Your NestJS Backend Should Notice Before a Human Ever Does

Peace Melodi — Tue, 14 Jul 2026 11:23:00 +0000

A single transaction rarely tells you anything is wrong. A customer moves five hundred dollars, that is normal. The same customer moves five hundred dollars nine times in an hour, to nine different accounts that have never received money from them before, that is not normal, and no human is watching closely enough, in real time, to catch that pattern the moment it happens. This is the actual job of anti money laundering monitoring, not catching one suspicious transaction, but noticing a pattern across many transactions before a person ever gets the chance to look.

Banks and fintechs are required to run this kind of monitoring, and compliance and financial crime hiring has grown sharply as regulatory pressure has increased. The technical challenge underneath that requirement is real and specific, a backend has to track behavior over time, not just validate a single request in isolation, and it has to do this consistently, without depending on a human noticing something later.

Why single transaction checks are not enough

A fraud check on one transaction can catch an obviously wrong amount or an obviously wrong account. AML monitoring is a different problem, since the individual transaction can look completely ordinary, and the concerning part only becomes visible when you look at a sequence of transactions together. Structuring deposits to stay just under a reporting threshold, moving money rapidly between accounts that rarely interact, or a sudden change in a customer's normal transaction pattern are all things that only become visible over a window of time.

This means the backend needs a way to track recent transaction history per customer, and evaluate that history against defined patterns, not just check the transaction currently in front of it.

Structuring a monitoring rule around a transaction history window

A dedicated service that pulls a customer's recent transaction history gives every rule a consistent, shared source of the same data, rather than each rule quietly fetching its own version of recent activity.

@Injectable()
export class TransactionHistoryService {
  constructor(
    @InjectRepository(Transaction)
    private readonly transactionRepo: Repository<Transaction>,
  ) {}

  async getRecentTransactions(
    customerId: string,
    windowMinutes: number,
  ): Promise<Transaction[]> {
    const since = new Date(Date.now() - windowMinutes * 60000);

    return this.transactionRepo.find({
      where: {
        customerId,
        createdAt: MoreThan(since),
      },
      order: { createdAt: 'DESC' },
    });
  }
}

Every monitoring rule can now ask for the same shared window of history, rather than each rule independently deciding what counts as recent.

Detecting structuring, transactions kept just under a threshold

A common pattern regulators specifically watch for is a customer breaking one large transaction into several smaller ones, each staying just under a reporting threshold. A rule built around the shared history service can check for this directly.

@Injectable()
export class StructuringRule {
  constructor(private readonly historyService: TransactionHistoryService) {}

  async evaluate(customerId: string): Promise<AmlFinding | null> {
    const reportingThreshold = 10000;
    const recent = await this.historyService.getRecentTransactions(customerId, 60);

    const nearThresholdCount = recent.filter(
      (transaction) =>
        transaction.amount >= reportingThreshold * 0.8 &&
        transaction.amount < reportingThreshold,
    ).length;

    if (nearThresholdCount >= 3) {
      return {
        rule: 'structuring',
        severity: 'high',
        reason: 'Multiple transactions just under the reporting threshold within an hour',
      };
    }

    return null;
  }
}

This kind of pattern is invisible if you only look at each transaction on its own. It only becomes visible once you look at the shared window of recent activity together.

Detecting a sudden change from a customer's normal behavior

A customer who normally sends small, occasional transfers, then suddenly sends a much larger transfer to a brand new recipient, represents a real shift worth flagging, even if no single rule about thresholds is triggered.

@Injectable()
export class BehaviorShiftRule {
  constructor(private readonly historyService: TransactionHistoryService) {}

  async evaluate(customerId: string): Promise<AmlFinding | null> {
    const recent = await this.historyService.getRecentTransactions(customerId, 43200);

    if (recent.length < 5) {
      return null;
    }

    const averageAmount =
      recent.reduce((sum, transaction) => sum + transaction.amount, 0) / recent.length;

    const latest = recent[0];

    if (latest.amount > averageAmount * 5) {
      return {
        rule: 'behavior_shift',
        severity: 'medium',
        reason: 'Latest transaction is far larger than this customer\'s typical amount',
      };
    }

    return null;
  }
}

Keeping the comparison relative to each customer's own history, rather than a single fixed number for everyone, means the rule stays meaningful across customers with very different normal spending patterns.

Running every rule together and recording what was found

A dedicated monitoring service brings every rule together, runs them against the same customer, and records any findings in a way that can be reviewed and audited later.

@Injectable()
export class AmlMonitoringService {
  constructor(
    private readonly structuringRule: StructuringRule,
    private readonly behaviorShiftRule: BehaviorShiftRule,
    @InjectRepository(AmlFinding)
    private readonly findingRepo: Repository<AmlFinding>,
  ) {}

  async monitorCustomer(customerId: string): Promise<AmlFinding[]> {
    const findings = (
      await Promise.all([
        this.structuringRule.evaluate(customerId),
        this.behaviorShiftRule.evaluate(customerId),
      ])
    ).filter((finding): finding is AmlFinding => finding !== null);

    for (const finding of findings) {
      await this.findingRepo.save({
        customerId,
        ...finding,
        detectedAt: new Date(),
      });
    }

    return findings;
  }
}

Recording every finding, even ones that turn out to be a false alarm after review, matters as much as detecting them, since a regulator or auditor needs to see that monitoring is actually running, not just that it occasionally catches something.

Running this on a schedule, not just at the moment of a transaction

Some patterns, like structuring, only fully reveal themselves once enough transactions have accumulated, which means checking only at the moment of a single transaction is not enough. Running monitoring on a schedule catches patterns that built up gradually.

@Injectable()
export class AmlScheduler {
  constructor(
    private readonly monitoringService: AmlMonitoringService,
    private readonly customerService: CustomerService,
  ) {}

  @Cron('*/15 * * * *')
  async runScheduledMonitoring(): Promise<void> {
    const activeCustomers = await this.customerService.findRecentlyActive();

    for (const customer of activeCustomers) {
      await this.monitoringService.monitorCustomer(customer.id);
    }
  }
}

Running this every fifteen minutes across recently active customers means a pattern building up across several transactions gets caught within a reasonable window, rather than only being noticed if someone happens to look later.

The bigger picture

None of these individual rules are complicated on their own. What actually matters is the structure underneath them, a shared way to pull a customer's recent history, rules that evaluate that history rather than a single transaction, and a schedule that keeps checking even when nothing happens to trigger a check at the exact moment of a transaction. NestJS gives you a clean place to keep each of these pieces separate, so new rules can be added later without disturbing the ones already running.

No rule set catches everything, and people trying to avoid detection keep adapting, but a system that actually looks at behavior over time, consistently and automatically, gives a bank or fintech a real chance of noticing something before a human ever has to go looking for it.

If you are building compliance or monitoring infrastructure and want this handled with real technical rigor, this is exactly the kind of work I focus on.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

NestJS Had Three Seconds to Decide if This Payment Was Fraud

Peace Melodi — Tue, 14 Jul 2026 10:18:31 +0000

A payment comes in through an instant payment rail. It has to settle in seconds, not minutes, not hours. Somewhere inside that tiny window, a bank or fintech has to decide whether this transaction looks suspicious enough to hold, question, or block, before the money is gone and settlement is final. There is no quiet background job that can check this later, because by the time a later check would run, the payment has already cleared.

This is the real shift that instant payment rails like FedNow and RTP have forced onto fraud detection. Fraud checks used to have some breathing room, a batch job overnight, a review the next morning. Instant settlement removes that breathing room completely, and a backend that cannot make a fast, reliable decision in that moment is a backend that either blocks legitimate payments out of caution, or lets suspicious ones through because checking properly took too long.

Why fraud detection has to run inline, not after the fact

The instinct from older systems is to record the transaction, let it settle, and flag anything suspicious afterward for a human to look at. That approach assumes there is time after settlement to act, and with instant payments, there usually is not. Fraud detection for these rails needs to sit directly in the path of the transaction, before settlement is confirmed, which means it has to be fast and structured cleanly, not bolted on as an afterthought.

Structuring fraud rules as their own dedicated module

Fraud rules change constantly, new patterns get identified, thresholds get adjusted, and new checks get added. Keeping this logic in its own module, separate from payment processing itself, means rules can evolve without touching the core payment flow every time.

export interface FraudRule {
  name: string;
  evaluate(transaction: TransactionContext): FraudRuleResult;
}

export interface FraudRuleResult {
  triggered: boolean;
  riskScore: number;
  reason?: string;
}

export interface TransactionContext {
  amount: number;
  currency: string;
  senderAccountId: string;
  recipientAccountId: string;
  recentTransactionCount: number;
  isNewRecipient: boolean;
}

@Injectable()
export class UnusualAmountRule implements FraudRule {
  name = 'unusual_amount';

  evaluate(transaction: TransactionContext): FraudRuleResult {
    const threshold = 5000;

    if (transaction.amount > threshold && transaction.isNewRecipient) {
      return {
        triggered: true,
        riskScore: 40,
        reason: 'Large payment to a new recipient',
      };
    }

    return { triggered: false, riskScore: 0 };
  }
}

@Injectable()
export class VelocityRule implements FraudRule {
  name = 'velocity';

  evaluate(transaction: TransactionContext): FraudRuleResult {
    if (transaction.recentTransactionCount > 10) {
      return {
        triggered: true,
        riskScore: 35,
        reason: 'Unusually high transaction frequency in a short window',
      };
    }

    return { triggered: false, riskScore: 0 };
  }
}

Each rule stays simple and focused on one specific pattern. Adding a new rule later means writing a new class that follows the same interface, not editing a large block of tangled logic.

Scoring a transaction with an interceptor before it reaches settlement

An interceptor is a natural place to run every active rule against an incoming transaction, before the request is allowed to continue toward the part of the system that actually settles the payment.

@Injectable()
export class FraudScoringInterceptor implements NestInterceptor {
  constructor(
    @Inject('FRAUD_RULES') private readonly rules: FraudRule[],
  ) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const request = context.switchToHttp().getRequest();
    const transaction: TransactionContext = request.body.transactionContext;

    const results = this.rules.map((rule) => ({
      rule: rule.name,
      ...rule.evaluate(transaction),
    }));

    const totalRiskScore = results.reduce(
      (sum, result) => sum + result.riskScore,
      0,
    );

    request.fraudAssessment = {
      totalRiskScore,
      triggeredRules: results.filter((result) => result.triggered),
    };

    return next.handle();
  }
}

Running this as an interceptor means every relevant endpoint gets consistent scoring, without each controller needing to remember to call the fraud logic manually.

Deciding what happens at each risk level

A raw risk score only matters if something clear happens because of it. A dedicated decision service keeps this logic in one place, so the thresholds for holding, reviewing, or blocking a transaction are defined once and applied consistently.

export enum FraudDecision {
  ALLOW = 'allow',
  HOLD_FOR_REVIEW = 'hold_for_review',
  BLOCK = 'block',
}

@Injectable()
export class FraudDecisionService {
  decide(totalRiskScore: number): FraudDecision {
    if (totalRiskScore >= 70) {
      return FraudDecision.BLOCK;
    }

    if (totalRiskScore >= 35) {
      return FraudDecision.HOLD_FOR_REVIEW;
    }

    return FraudDecision.ALLOW;
  }
}

@Injectable()
export class SettlementService {
  constructor(private readonly decisionService: FraudDecisionService) {}

  async processTransaction(request: any): Promise<SettlementResult> {
    const decision = this.decisionService.decide(
      request.fraudAssessment.totalRiskScore,
    );

    if (decision === FraudDecision.BLOCK) {
      throw new ForbiddenException('Transaction blocked due to fraud risk');
    }

    if (decision === FraudDecision.HOLD_FOR_REVIEW) {
      return this.holdForManualReview(request);
    }

    return this.settle(request);
  }

  private async holdForManualReview(request: any): Promise<SettlementResult> {
    return { status: 'held', reason: 'Pending manual fraud review' };
  }

  private async settle(request: any): Promise<SettlementResult> {
    return { status: 'settled' };
  }
}

This keeps the actual settlement logic clean, since it only needs to ask what the decision was, not repeat fraud logic itself.

Keeping this fast enough to matter

None of this is useful if it slows settlement down past what an instant payment rail allows. Rules need to stay simple and avoid slow external calls wherever possible, and anything that genuinely needs external data, like a recipient reputation check, should be cached aggressively so a repeated check does not cost a fresh lookup every time.

@Injectable()
export class RecipientReputationRule implements FraudRule {
  name = 'recipient_reputation';
  private cache = new Map<string, { score: number; cachedAt: number }>();
  private readonly cacheTtlMs = 30000;

  constructor(private readonly reputationService: ReputationService) {}

  async evaluateWithCache(recipientAccountId: string): Promise<number> {
    const cached = this.cache.get(recipientAccountId);

    if (cached && Date.now() - cached.cachedAt < this.cacheTtlMs) {
      return cached.score;
    }

    const score = await this.reputationService.getScore(recipientAccountId);
    this.cache.set(recipientAccountId, { score, cachedAt: Date.now() });

    return score;
  }
}

A short cache window like this keeps the check fast for the vast majority of repeated recipients, while still refreshing regularly enough that reputation data does not go stale for long.

The bigger picture

Fraud detection built for instant payments is not just about having good rules, it is about having a system structured so those rules can run quickly, consistently, and in the right place, before settlement, not after. What NestJS gives you here is a clean separation between the rules themselves, the scoring step, and the decision that follows, which means the fraud logic can keep evolving without destabilizing the payment flow it sits inside.

No rules engine catches everything, and fraud patterns keep changing, but a system built this way at least gives a bank or fintech a fighting chance of catching what matters in the only window that is left to catch it.

If you are building payment infrastructure that needs fraud checks running fast and reliably inside a real settlement flow, this is exactly the kind of work I focus on.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

How to Validate ISO 20022 Payment Messages in NestJS Before Money Moves

Peace Melodi — Mon, 13 Jul 2026 15:17:03 +0000

A bank receives a payment instruction from another bank. Before a single dollar or pound moves, that incoming message has to be checked completely, the structure has to be correct, the amount has to make sense, the account references have to be valid, and nothing about the message can be trusted just because it arrived on a trusted network. This is the part of payment infrastructure that rarely gets discussed publicly, but it is exactly where a real financial system either holds up under pressure or quietly lets something wrong slip through.

ISO 20022 is the structured messaging standard that banks and payment networks worldwide are actively moving to right now, replacing older, looser formats across systems like Fedwire, SWIFT, and instant payment rails. The format itself is well documented. What is much less documented is how to actually validate these messages properly inside a real backend, before that data ever touches an account balance.

Why validation cannot be an afterthought here

A normal API might validate a request and move on. A payment message is different, because a mistake here does not just produce an error, it can move real money incorrectly. An incoming ISO 20022 message needs to be checked at several levels, its overall structure needs to match what is expected, required fields need to actually be present, amounts and currencies need to be sensible, and the message needs to be checked against messages already processed, so the same payment instruction cannot accidentally be applied twice.

NestJS gives you a natural place to enforce every one of these checks consistently, instead of leaving validation logic scattered across different parts of the codebase.

Modeling the incoming message as a strict structure

The first real step is representing the incoming payment message as an explicit, strongly typed structure, rather than accepting loosely shaped data and hoping the important fields happen to be there. Using class validator decorators means the shape of a valid message is defined once, clearly, and enforced automatically.

import { Type } from 'class-transformer';
import {
  IsString,
  IsNotEmpty,
  IsNumber,
  IsPositive,
  IsISO4217CurrencyCode,
  ValidateNested,
  IsDateString,
} from 'class-validator';

export class GroupHeaderDto {
  @IsString()
  @IsNotEmpty()
  messageId: string;

  @IsDateString()
  creationDateTime: string;

  @IsNumber()
  @IsPositive()
  numberOfTransactions: number;
}

export class PaymentAmountDto {
  @IsNumber()
  @IsPositive()
  amount: number;

  @IsISO4217CurrencyCode()
  currency: string;
}

export class PaymentInstructionDto {
  @IsString()
  @IsNotEmpty()
  endToEndId: string;

  @ValidateNested()
  @Type(() => PaymentAmountDto)
  amount: PaymentAmountDto;

  @IsString()
  @IsNotEmpty()
  debtorAccount: string;

  @IsString()
  @IsNotEmpty()
  creditorAccount: string;
}

export class Pacs008Dto {
  @ValidateNested()
  @Type(() => GroupHeaderDto)
  groupHeader: GroupHeaderDto;

  @ValidateNested({ each: true })
  @Type(() => PaymentInstructionDto)
  paymentInstructions: PaymentInstructionDto[];
}

This structure alone rules out a large category of problems before any business logic runs. A message missing a currency code, carrying a negative amount, or missing an account reference simply fails validation immediately, rather than silently reaching code that assumes the data is already correct.

Enforcing validation automatically with a pipe

Defining the structure is only useful if it is actually enforced on every incoming message. NestJS's built in validation pipe applies these checks automatically at the point the request enters the system, so no controller can accidentally skip this step.

import { ValidationPipe } from '@nestjs/common';

app.useGlobalPipes(
  new ValidationPipe({
    whitelist: true,
    forbidNonWhitelisted: true,
    transform: true,
  }),
);

Setting forbidNonWhitelisted to true matters specifically for payment messages, since it means any unexpected field in the incoming message causes an immediate rejection, rather than silently being ignored. For financial data, silently ignoring something unexpected is far more dangerous than rejecting it outright.

Rejecting duplicate messages before they are processed

A message might arrive more than once, because of a retry, a network issue, or a resend from the sending system. Processing the same payment instruction twice is exactly the kind of mistake that leads to money moving when it should not. A dedicated service checking the message id from the group header, before any processing happens, protects against this directly.

@Injectable()
export class MessageDeduplicationService {
  constructor(
    @InjectRepository(ProcessedMessage)
    private readonly processedRepo: Repository<ProcessedMessage>,
  ) {}

  async assertNotProcessed(messageId: string): Promise<void> {
    const existing = await this.processedRepo.findOne({
      where: { messageId },
    });

    if (existing) {
      throw new ConflictException(
        `Message ${messageId} has already been processed`,
      );
    }
  }

  async markProcessed(messageId: string): Promise<void> {
    await this.processedRepo.save({
      messageId,
      processedAt: new Date(),
    });
  }
}

Checking this before any payment instruction is applied, and recording it immediately once processing begins, means a duplicate message is caught and rejected cleanly, rather than resulting in the same transfer happening more than once.

Bringing validation together with a guard

A guard is a natural place to run these checks before a request is even allowed to reach the controller, keeping this discipline consistent no matter which endpoint receives the message.

@Injectable()
export class PaymentMessageGuard implements CanActivate {
  constructor(
    private readonly deduplicationService: MessageDeduplicationService,
  ) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const messageId = request.body?.groupHeader?.messageId;

    if (!messageId) {
      throw new BadRequestException('Missing message id in group header');
    }

    await this.deduplicationService.assertNotProcessed(messageId);

    return true;
  }
}

With this guard in place, every incoming payment message is checked for a valid structure through the pipe, and checked for duplication through the guard, before the controller or any service touches an actual account balance.

The bigger picture

None of this complexity comes from NestJS itself, it comes from the nature of the message, a payment instruction carries real financial weight, and a mistake in handling it is not just a bug, it is money moving incorrectly. What NestJS gives you is a clean, enforceable place to put each layer of protection, strict typing for the message shape, a pipe that rejects anything malformed automatically, and a guard that stops duplicate processing before it happens.

Banks and payment providers are in the middle of this migration right now, and the backend systems handling these messages need to treat validation as a first class concern, not something added later once a problem has already occurred.

If your team is working through ISO 20022 integration and wants this handled with the rigor it actually requires, this is exactly the kind of work I focus on.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

The Second Your Money Changes Currency, NestJS Has to Catch Up

Peace Melodi — Mon, 13 Jul 2026 14:39:13 +0000

A customer holds a wallet in dollars. She wants to send money to a supplier in the United Kingdom who only accepts pounds. Somewhere in between, that money has to exist briefly in a form that is neither dollars nor pounds, a kind of intermediate value that gets converted at a specific rate, at a specific time, and every step of that conversion has to be recorded precisely enough that both sides can trust the final number.

This is the part of fintech backend work that looks simple from the outside and turns out to be one of the fastest ways to lose real money if it is modeled carelessly. A wallet that only ever holds one currency is a spreadsheet. A wallet that has to hold several currencies, convert between them, and stay correct under concurrent access is a real system, and it needs to be treated like one from the start.

Why a single balance column breaks immediately

The natural first instinct is to give a wallet a single balance field and a currency field, then update the balance whenever money moves. This works fine until a customer holds funds in more than one currency at once, which is the entire point of a multi currency wallet. The moment that happens, a single balance column cannot represent reality anymore.

The correct starting point is treating each currency a wallet holds as its own separate, trackable balance, all belonging to the same wallet owner.

@Entity()
export class Wallet {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  ownerId: string;

  @OneToMany(() => WalletBalance, (balance) => balance.wallet)
  balances: WalletBalance[];
}

@Entity()
export class WalletBalance {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @ManyToOne(() => Wallet, (wallet) => wallet.balances)
  wallet: Wallet;

  @Column()
  currency: string;

  @Column('numeric', { precision: 18, scale: 6 })
  amount: string;

  @VersionColumn()
  version: number;
}

Notice the amount is stored as a numeric string, not a floating point number. Money should never be represented as a float in a backend, since floating point rounding errors are exactly the kind of thing that quietly corrupts financial data over time.

Structuring a currency conversion as its own tracked operation

Converting money between currencies is not a single update, it is really two linked operations, a debit in one currency and a credit in another, tied together by the exchange rate that was actually used at that exact moment. That rate needs to be stored, not just applied and forgotten, because a customer or an auditor may later ask exactly what rate was used for a specific transfer.

@Entity()
export class CurrencyConversion {
  @PrimaryGeneratedColumn('uuid')
  id: string;

  @Column()
  walletId: string;

  @Column()
  fromCurrency: string;

  @Column()
  toCurrency: string;

  @Column('numeric', { precision: 18, scale: 6 })
  fromAmount: string;

  @Column('numeric', { precision: 18, scale: 6 })
  toAmount: string;

  @Column('numeric', { precision: 18, scale: 8 })
  exchangeRate: string;

  @CreateDateColumn()
  executedAt: Date;
}

Recording the conversion this way means the wallet balances always reflect the outcome, and the conversion record explains exactly how that outcome was reached.

Keeping conversions correct under concurrent access

Two conversions hitting the same wallet balance at nearly the same moment is a real risk, especially at any real scale. NestJS's dependency injection makes it straightforward to keep this logic in one dedicated service, and using the version column defined earlier gives you optimistic locking, so a conflicting update fails cleanly instead of silently overwriting another one.

@Injectable()
export class ConversionService {
  constructor(
    @InjectRepository(WalletBalance)
    private readonly balanceRepo: Repository<WalletBalance>,
    @InjectRepository(CurrencyConversion)
    private readonly conversionRepo: Repository<CurrencyConversion>,
    private readonly rateService: ExchangeRateService,
  ) {}

  async convert(
    walletId: string,
    fromCurrency: string,
    toCurrency: string,
    fromAmount: string,
  ): Promise<CurrencyConversion> {
    const fromBalance = await this.balanceRepo.findOneOrFail({
      where: { wallet: { id: walletId }, currency: fromCurrency },
    });

    if (Number(fromBalance.amount) < Number(fromAmount)) {
      throw new BadRequestException('Insufficient balance for conversion');
    }

    const rate = await this.rateService.getCurrentRate(fromCurrency, toCurrency);
    const toAmount = (Number(fromAmount) * rate).toFixed(6);

    let toBalance = await this.balanceRepo.findOne({
      where: { wallet: { id: walletId }, currency: toCurrency },
    });

    if (!toBalance) {
      toBalance = this.balanceRepo.create({
        wallet: { id: walletId },
        currency: toCurrency,
        amount: '0',
      });
    }

    fromBalance.amount = (Number(fromBalance.amount) - Number(fromAmount)).toFixed(6);
    toBalance.amount = (Number(toBalance.amount) + Number(toAmount)).toFixed(6);

    await this.balanceRepo.save([fromBalance, toBalance]);

    return this.conversionRepo.save({
      walletId,
      fromCurrency,
      toCurrency,
      fromAmount,
      toAmount,
      exchangeRate: rate.toString(),
    });
  }
}

If two conversions try to update the same balance at once, the version column causes the second save to fail with an optimistic locking error, which the caller can catch and safely retry against the fresh balance, rather than silently applying two updates on top of stale data.

Handling exchange rates as something that changes constantly

Exchange rates are not static values you hardcode, they shift constantly and need to come from a reliable source, cached briefly so you are not calling an external provider on every single request. A dedicated module keeps this concern separate from the wallet logic itself.

@Injectable()
export class ExchangeRateService {
  private cache = new Map<string, { rate: number; fetchedAt: number }>();
  private readonly cacheTtlMs = 60000;

  constructor(private readonly httpService: HttpService) {}

  async getCurrentRate(from: string, to: string): Promise<number> {
    const key = `${from}_${to}`;
    const cached = this.cache.get(key);

    if (cached && Date.now() - cached.fetchedAt < this.cacheTtlMs) {
      return cached.rate;
    }

    const response = await firstValueFrom(
      this.httpService.get(`/rates?from=${from}&to=${to}`),
    );

    const rate = response.data.rate;
    this.cache.set(key, { rate, fetchedAt: Date.now() });

    return rate;
  }
}

Keeping the cache window short matters here. Too long and customers get stale rates that do not match what the provider is currently quoting, too short and you are calling an external API on nearly every request. A minute is often a reasonable starting point, adjusted based on how volatile the currency pair actually is.

The bigger picture

None of this complexity comes from NestJS itself, it comes from the nature of money that moves between currencies. What NestJS gives you is a clean place to put each concern, wallet balances as their own entities, conversions as their own auditable records, exchange rates handled by a dedicated service, and concurrency safety built in through the same tools the framework already gives you for other parts of the system.

A multi currency wallet that looks simple in a demo can fall apart quickly in production if any of these pieces are treated as an afterthought. Getting the structure right early is far cheaper than untangling incorrect balances after real customer money has already moved through the system.

If you are building a wallet system that needs to handle multiple currencies correctly under real production conditions, this is exactly the kind of work I focus on.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

NestJS Remembers Consent Long After the Customer Forgets

Peace Melodi — Mon, 13 Jul 2026 14:11:23 +0000

A customer connects their bank account to a budgeting app. Three months later they forget the connection even exists. Under PSD2, that connection cannot just quietly keep working forever, it has to be re confirmed periodically, it can be partially revoked for one account while staying active for another, and if the customer never comes back to reauthorize it, access has to stop automatically, not because someone remembered to check, but because the system itself enforces it.

This is the part of open banking that trips up a lot of backends. Building the endpoints that move money or fetch transactions is the easy part. Correctly modeling consent as something that moves through real, regulated states over time is where a lot of the actual engineering difficulty lives, and it is also one of the most specific, checkable requirements a regulator or an auditor will actually test.

Why a simple yes or no is not enough

The instinct is to treat consent as a single boolean, granted or not granted. PSD2 does not work that way. Consent has a defined shape, it starts, it gets confirmed, it becomes active, it eventually needs reauthorization, it can expire, and it can be revoked, sometimes for specific accounts rather than the whole connection at once.

Treating this as a boolean means you lose the ability to answer basic questions later, like when exactly did this consent become active, or was this specific account still authorized at the moment this data was accessed. Those are exactly the questions that come up during a compliance review.

Modeling consent as a real state machine

The first real step is representing consent as an explicit set of states, with clear rules about which transitions are actually allowed.

export enum ConsentStatus {
  INITIATED = 'initiated',
  AUTHORIZED = 'authorized',
  ACTIVE = 'active',
  REAUTH_PENDING = 'reauth_pending',
  EXPIRED = 'expired',
  REVOKED = 'revoked',
}

const ALLOWED_TRANSITIONS: Record<ConsentStatus, ConsentStatus[]> = {
  [ConsentStatus.INITIATED]: [ConsentStatus.AUTHORIZED, ConsentStatus.REVOKED],
  [ConsentStatus.AUTHORIZED]: [ConsentStatus.ACTIVE, ConsentStatus.REVOKED],
  [ConsentStatus.ACTIVE]: [ConsentStatus.REAUTH_PENDING, ConsentStatus.REVOKED],
  [ConsentStatus.REAUTH_PENDING]: [ConsentStatus.ACTIVE, ConsentStatus.EXPIRED, ConsentStatus.REVOKED],
  [ConsentStatus.EXPIRED]: [],
  [ConsentStatus.REVOKED]: [],
};

Defining allowed transitions explicitly, rather than just setting a new status wherever convenient in the code, prevents a whole category of bugs where consent accidentally moves backward, or jumps into a state it was never actually supposed to reach.

Enforcing transitions through a dedicated service

A service that owns consent transitions, and refuses anything not explicitly allowed, keeps this logic in one place instead of scattered across every controller that happens to touch consent.

@Injectable()
export class ConsentService {
  constructor(
    @InjectRepository(Consent)
    private readonly consentRepo: Repository<Consent>,
  ) {}

  async transition(consentId: string, nextStatus: ConsentStatus): Promise<Consent> {
    const consent = await this.consentRepo.findOneOrFail({ where: { id: consentId } });

    const allowed = ALLOWED_TRANSITIONS[consent.status];
    if (!allowed.includes(nextStatus)) {
      throw new BadRequestException(
        `Cannot move consent from ${consent.status} to ${nextStatus}`,
      );
    }

    consent.status = nextStatus;
    consent.updatedAt = new Date();
    await this.consentRepo.save(consent);

    return consent;
  }
}

Any attempt to move consent into an invalid state fails loudly and immediately, rather than silently corrupting the record, which matters a great deal when this record might be examined later as evidence of compliance.

Account level granularity, not just one flag per connection

A real connection often covers several accounts, and PSD2 allows a customer to revoke access to just one of them without ending the entire relationship. This means consent cannot only live at the connection level, it needs to track which specific accounts remain authorized.

@Entity()
export class Consent {
  @Column({ type: 'enum', enum: ConsentStatus })
  status: ConsentStatus;

  @Column()
  customerId: string;

  @Column()
  thirdPartyId: string;

  @Column('simple-array')
  authorizedAccountIds: string[];

  @Column({ nullable: true })
  expiresAt: Date;
}

@Injectable()
export class AccountConsentService {
  constructor(private readonly consentRepo: Repository<Consent>) {}

  async revokeAccount(consentId: string, accountId: string): Promise<void> {
    const consent = await this.consentRepo.findOneOrFail({ where: { id: consentId } });

    consent.authorizedAccountIds = consent.authorizedAccountIds.filter(
      (id) => id !== accountId,
    );

    if (consent.authorizedAccountIds.length === 0) {
      consent.status = ConsentStatus.REVOKED;
    }

    await this.consentRepo.save(consent);
  }
}

The connection as a whole only moves to fully revoked once every individual account has been removed, which matches how PSD2 actually expects partial revocation to behave.

Automatically expiring consent that nobody reauthorized

PSD2 generally expects consent to require periodic reauthorization, commonly around ninety days. This should not depend on someone remembering to check, it needs to run automatically.

@Injectable()
export class ConsentExpiryScheduler {
  constructor(private readonly consentService: ConsentService) {}

  @Cron('0 2 * * *')
  async expireStaleConsents(): Promise<void> {
    const staleConsents = await this.consentService.findConsentsPastReauthWindow();

    for (const consent of staleConsents) {
      await this.consentService.transition(consent.id, ConsentStatus.EXPIRED);
    }
  }
}

Running this daily means a customer who never comes back to reauthorize loses access automatically, on schedule, without depending on any manual step, which is exactly the guarantee a regulator expects this kind of system to provide.

The bigger picture

None of this is really about payments or transaction data. It is about being able to prove, at any point in time, exactly what a customer agreed to, for which accounts, and whether that agreement is still valid right now. NestJS does not know anything about PSD2 specifically, but its structure, a dedicated service owning transitions, a scheduler enforcing expiry automatically, entities that track granular state, gives you a natural place to build this correctly instead of leaving consent logic scattered and inconsistent.

Getting this right early matters more than it might seem, since consent handling is exactly the kind of thing regulators and auditors check closely, and it is far more expensive to retrofit a proper state machine into a system that started with a simple boolean than to build it correctly from the start.

If you are building open banking infrastructure and want consent handled with this level of rigor from day one, this is exactly the kind of work I focus on.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi

A Bank Learned the Hard Way What Section 1033 Actually Demands, NestJS Made It Easier

Peace Melodi — Mon, 13 Jul 2026 13:22:16 +0000

A bank's engineering team gets told they now have to expose customer account data through an API, so that customers can securely share their own financial information with other apps and services if they choose to. On paper this sounds like a normal API project, build some endpoints, add authentication, done. In practice, it is one of the most regulated pieces of software a bank will build, and treating it like a normal API is exactly how teams end up scrambling close to a deadline.

This is the reality many US banks are dealing with right now. Section 1033 requires banks to expose consumer financial data through APIs to licensed third parties, and the deadline pressure around this has already pushed a lot of teams into building this quickly, sometimes without fully appreciating how different this kind of API is from anything else in their system.

Why this is not just another API

A normal internal API answers to your own product team. This kind of API answers to regulators, to security auditors, and to every third party company that connects to it, each of whom is trusting that your bank handled their customers' financial data correctly. That changes what actually matters here.

Four things come up constantly when this is done properly. Consent has to be tracked as a real, auditable lifecycle, not just a yes or no flag. Every access to sensitive data needs a durable record of who asked, when, and why. Performance and uptime are not just good practice, they are frequently treated as compliance requirements in themselves. And the API has to be built in a way that can evolve without breaking every third party integration relying on it.

NestJS is not going to make these requirements disappear, but its structure, guards, interceptors, modules, gives you a clean, consistent place to enforce each of them properly, instead of leaving compliance logic scattered across individual controllers.

Treating consent as a real lifecycle, not a flag

A common early mistake is representing consent as a simple boolean, the customer said yes, so access is allowed. Real consent has states, it can be granted, it can expire, it can be partially revoked for one account but not another, and every transition needs to be provable later if a regulator asks.

export enum ConsentStatus {
  INITIATED = 'initiated',
  AUTHORIZED = 'authorized',
  ACTIVE = 'active',
  REAUTH_PENDING = 'reauth_pending',
  EXPIRED = 'expired',
  REVOKED = 'revoked',
}

@Entity()
export class Consent {
  @Column({ type: 'enum', enum: ConsentStatus })
  status: ConsentStatus;

  @Column()
  customerId: string;

  @Column()
  thirdPartyId: string;

  @Column('simple-array')
  authorizedAccountIds: string[];

  @Column()
  grantedAt: Date;

  @Column({ nullable: true })
  expiresAt: Date;
}

A dedicated guard can then check the actual current state of consent before allowing any request through, rather than trusting a token that might not reflect the latest state.

@Injectable()
export class ConsentGuard implements CanActivate {
  constructor(private readonly consentService: ConsentService) {}

  async canActivate(context: ExecutionContext): Promise<boolean> {
    const request = context.switchToHttp().getRequest();
    const consent = await this.consentService.findActiveConsent(
      request.params.accountId,
      request.thirdPartyId,
    );

    if (!consent || consent.status !== ConsentStatus.ACTIVE) {
      throw new ForbiddenException('No active consent for this account');
    }

    return true;
  }
}

Keeping this as its own guard, checked on every relevant request, means consent enforcement lives in one place, and it stays accurate even if consent is revoked in the middle of an otherwise valid session.

Making every access to sensitive data provable later

Regulators and auditors are not just interested in whether access was allowed, they want to know it actually happened, when, and for what account. An interceptor is a natural place to record this consistently, without needing every controller to remember to log it manually.

@Injectable()
export class DataAccessAuditInterceptor implements NestInterceptor {
  constructor(
    @InjectRepository(AccessLog)
    private readonly accessLogRepo: Repository<AccessLog>,
  ) {}

  intercept(context: ExecutionContext, next: CallHandler): Observable<any> {
    const request = context.switchToHttp().getRequest();

    return next.handle().pipe(
      tap(async () => {
        await this.accessLogRepo.save({
          thirdPartyId: request.thirdPartyId,
          accountId: request.params.accountId,
          endpoint: request.url,
          accessedAt: new Date(),
        });
      }),
    );
  }
}

This produces a durable, queryable record of every access to a customer's financial data, which is exactly the kind of evidence a compliance review or a customer dispute is going to ask for later.

Treating uptime as a requirement, not an aspiration

Many of these APIs come with real performance and availability expectations attached, not just a general goal of being fast. NestJS's built in throttling module is a straightforward way to protect the system from being overwhelmed, which matters both for reliability and for meeting response time expectations under load.

@Module({
  imports: [
    ThrottlerModule.forRoot([
      {
        ttl: 60000,
        limit: 100,
      },
    ]),
  ],
})
export class AppModule {}

@UseGuards(ThrottlerGuard)
@Controller('accounts')
export class AccountDataController {
  @Get(':accountId/transactions')
  getTransactions(@Param('accountId') accountId: string) {
    return this.accountService.getTransactions(accountId);
  }
}

This is a small piece of configuration, but it directly protects against one of the more common ways these APIs fail their availability targets, a single misbehaving client or a traffic spike degrading the experience for everyone else.

Building an API that can change without breaking every integration

Once third parties are connected to your API, changing it carelessly risks breaking every one of those integrations at once. NestJS supports URL based versioning natively, which gives you a clean path to introduce changes without forcing every existing integration to update immediately.

app.enableVersioning({
  type: VersioningType.URI,
});

@Controller({
  path: 'accounts',
  version: '1',
})
export class AccountDataControllerV1 {
  // existing behavior stays stable for current integrations
}

@Controller({
  path: 'accounts',
  version: '2',
})
export class AccountDataControllerV2 {
  // new behavior, adopted by integrations at their own pace
}

This lets you evolve the API responsibly, giving third parties a real migration window instead of forcing a breaking change on everyone simultaneously.

The bigger picture

None of these pieces, consent tracking, audit logging, rate limiting, versioning, are unique to NestJS. What NestJS gives you is a consistent, enforceable place to put each of them, a guard that cannot be accidentally skipped, an interceptor that logs access without relying on developers remembering to do it manually, and a module structure that keeps this discipline consistent as the API grows.

Building this kind of API is not primarily a technical challenge, most of the individual pieces are well understood. The real difficulty is treating it with the seriousness it actually requires from the start, rather than discovering the gaps during an audit or after a real customer complaint.

If your team is working through Section 1033 compliance and wants this built properly the first time, this is exactly the kind of work I focus on.

LinkedIn: https://www.linkedin.com/in/melodi-peace-406494368
GitHub: https://github.com/PeaceMelodi