Can You Help Me Break a Commission Payment ISO 20022 Integration Into User Stories?

March 26, 2026 by Jeff Ward, Claude (Anthropic) (Beneficial Strategies)

Hey, I’m a project planner and we’re doing an ISO 20022 integration with our bank. From our existing Sales Commissioning system, I need to be able to originate — right now from a screen, but later from an automatic process — a system that takes bonuses awarded each month and creates a Pain.001 that gets routed to our bank. I need to give people status on when it went out and what was being paid, and I also need to show when it was acknowledged by the bank when we receive a Pain.002 back. Right now I’m the only one using this ISO 20022 MCP AI tool — it hasn’t gained corporate acceptance yet. I’ll be dealing with a front-end dev team, a back-end dev team, and a QA team. We have two-week scrums. We like small user stories you can actually demo when they’re done. Can you help me break this into user stories with rough sizes and basic acceptance criteria?

That’s a well-scoped problem — and yes, absolutely. Let me start by confirming you have the right message types, because that shapes everything downstream.

[Calling GetPopularMessages on the ISO 20022 MCP Server…]

You’ve named them correctly. pain.001 — Customer Credit Transfer Initiation is the standard corporate-to-bank payment instruction: your Sales Commissioning system sends it to tell the bank “pay these people.” pain.002 — Payment Status Report is the bank’s response: accepted, rejected, or pending. They’re always used as a pair.

Both live in the pain (Payments Initiation) business area — the corporate side of the payment lifecycle, before the funds actually move between banks. You’re not dealing with pacs or camt; those are the interbank and cash-management layers that happen after the bank receives your pain.001.

Before I build out the stories, let me ask a few things that will change the sizing significantly.

Claude: What does your back-end stack look like? .NET, Java, Node, Python — or something else?

PM: .NET — C# back end, React front end.

Claude: Good. One more question before we get into stories: will the development teams themselves be using the ISO 20022 MCP Server alongside their AI tool of choice during the implementation — or are you the only seat right now?

PM: That’s a good question. What would the difference actually look like? Can you price it both ways?

Claude: Glad you asked, because it actually matters for your sizing.

Without the tool, a back-end developer implementing pain.001 serialization faces roughly 150 fields across nested message components. They need to read the spec to identify which are mandatory, which are conditional, what the code sets mean, and how the bank’s specific requirements layer on top. That’s not fast. Depending on how thorough they are, you’re looking at one to three days of spec comprehension before a line of code is written. The same problem hits QA when they need to build test cases — they need to understand the message structure to know what edge cases matter.

With the MCP Server, any developer can ask “what are the mandatory fields in pain.001 for a credit transfer?” or “generate a C# record for a CreditTransferTransaction” and get a verified, spec-grounded answer in seconds. The XML samples, field validations, and data model are all queryable. The QA team can generate realistic test data on demand.

Here’s the rough math for your project:

Without MCP With MCP ($29/seat/month)
Back-end spec ramp (2 devs × 2 days) ~32 dev-hours ~4 dev-hours
Pain.002 parsing research ~8 dev-hours ~1 dev-hour
QA test data construction ~8 dev-hours ~1 dev-hour
Total estimated savings baseline ~42 dev-hours

At a conservative blended rate, 42 dev-hours easily covers several months of Pro seats for your whole team. The harder-to-quantify benefit is accuracy — spec misreadings that slip through to QA or, worse, to the bank, are expensive. That’s where the tool pays for itself in risk reduction.

My suggestion: equip your two back-end devs and one QA engineer with Pro seats for the duration of the project. That’s three seats at $29/month — $87/month. If the project spans two sprints of active development, your total tooling cost is under $200.

PM: That’s compelling. I’ll pitch it. Let’s assume the teams have the tool. Does that change the story sizes?

Claude: It does — mostly in the back-end stories. Spec-related research tasks that would otherwise be 8-pointers drop to 5 or even 3. I’ll note that in the sizing. Let me ask one more practical question: how is the bank connectivity set up? SFTP file drop, a REST/SOAP API, or do you not know yet?

PM: We don’t know yet. The bank integration meeting hasn’t happened.

Claude: That’s common, and it’s important. I’ll structure the bank connectivity as its own back-end story with a stub interface so the other work can proceed in parallel. When the bank meeting happens, that story becomes a targeted integration — it doesn’t require re-work on the payment generation or the UI.

One more: does the front-end team use any particular component library? Anything that affects form scaffolding?

PM: Material UI.

Claude: Perfect. That keeps the FE stories tight. Here’s your sprint plan.

Sprint Plan: Commission Payment ISO 20022 Integration

Assumptions

Epic 1 — Pain.001 Generation

Story 1.1 · Back-end · 3 pts As a developer, I want a C# domain model representing a commission payment batch (payee, amount, currency, reference), So that the payment data from Sales Commissioning can be mapped into an ISO 20022 structure.

Acceptance criteria:

With MCP: A developer queries the MCP Server for mandatory pain.001 fields and generates the initial C# records in one session. Sized at 3 pts (was 5 without tooling).

Story 1.2 · Back-end · 5 pts As a system, I want to serialize a commission payment batch into a valid pain.001.001.09 XML document, So that the message can be submitted to the bank.

Acceptance criteria:

With MCP: The serialization logic is scaffolded from an MCP-generated XML sample. Sized at 5 pts (was 8 without tooling).

Story 1.3 · Back-end · 3 pts As a developer, I want a stubbed bank submission interface with a file/API abstraction, So that upstream stories can integrate against it before the real bank connectivity is determined.

Acceptance criteria:

Epic 2 — Manual Origination UI

Story 2.1 · Front-end · 3 pts As a payroll administrator, I want to view the current month’s commission batch before submitting it, So that I can review what will be paid before sending to the bank.

Acceptance criteria:

Story 2.2 · Front-end · 3 pts As a payroll administrator, I want a “Submit to Bank” button that initiates the pain.001 submission, So that I can originate the payment with a single confirmed action.

Acceptance criteria:

Story 2.3 · Front-end · 2 pts As a payroll administrator, I want to see a submission status indicator after sending, So that I know the pain.001 was dispatched successfully.

Acceptance criteria:

Epic 3 — Pain.002 Acknowledgment Processing

Story 3.1 · Back-end · 5 pts As a system, I want to receive and parse a pain.002 Payment Status Report from the bank, So that we can record whether the payment was accepted or rejected.

Acceptance criteria:

With MCP: Status code meanings and pain.002 structure are queried directly — no manual spec-reading. Sized at 5 pts (was 8 without tooling).

Story 3.2 · Back-end · 3 pts As a system, I want a polling or webhook endpoint to receive pain.002 messages from the bank, So that acknowledgments are captured automatically without manual intervention.

Acceptance criteria:

Story 3.3 · Front-end · 2 pts As a payroll administrator, I want to see the bank’s acknowledgment status on the payment screen, So that I can confirm the bank accepted the payment file.

Acceptance criteria:

Epic 4 — Automated Batch Origination

Story 4.1 · Back-end · 5 pts As a system, I want a scheduled process that automatically originates a pain.001 on a configured schedule (e.g. first business day of the month), So that commission payments do not require manual intervention each cycle.

Acceptance criteria:

Story 4.2 · Back-end · 2 pts As an administrator, I want to be able to disable the automated process temporarily, So that we can hold a payment cycle when needed (e.g. during a system freeze or audit).

Acceptance criteria:

Epic 5 — Bank Connectivity (Placeholder)

Story 5.1 · Back-end · TBD — size after bank meeting As a system, I want to submit pain.001 XML to the bank via their confirmed channel (SFTP / REST / SOAP), So that the real submission replaces the stub.

Acceptance criteria:

Epic 6 — QA

Story 6.1 · QA · 5 pts As a QA engineer, I want an integration test suite covering the pain.001 generation and pain.002 parsing flows, So that regressions are caught before deployment.

Acceptance criteria:

With MCP: QA generates test XML samples directly from the spec. Sized at 5 pts (was 8 without tooling).

Summary Sizing

Story Team Points
1.1 Domain model Back-end 3
1.2 Pain.001 serialization Back-end 5
1.3 Bank submission stub Back-end 3
2.1 Batch review screen Front-end 3
2.2 Submit to bank action Front-end 3
2.3 Submission status display Front-end 2
3.1 Pain.002 parsing Back-end 5
3.2 Pain.002 receiver Back-end 3
3.3 Acknowledgment display Front-end 2
4.1 Automated batch origination Back-end 5
4.2 Automation disable toggle Back-end 2
5.1 Real bank connectivity Back-end TBD
6.1 Integration test suite QA 5
Total (excl. bank connectivity) 41 pts

At a typical team velocity of 20–25 points per sprint, the scoped work fits in two sprints of parallel development, with bank connectivity landing in Sprint 3 once that meeting happens.

All I did was describe the project. The MCP Server identified the right message types, grounded the field requirements, helped size the back-end stories more aggressively because the team would have spec access on demand, and priced out whether the tooling would pay for itself — it does, before the first sprint ends. The project plan practically wrote itself.

If you’d like to see the actual pain.001 field structure, generate a sample XML for Story 1.2, or draft C# records for the domain model in Story 1.1 — just ask. The spec is one question away.