How we deliver banking-grade software
with AI agents across the whole SDLC.
Tested. Production-grade code that makes you sleep at night.
Faster delivery, with the same controls.
Banking-grade software, properly tested, ready for release review as soon as it passes the quality gates. Release cadence follows the client's own process and the maturity of the product.
Your team thinks. The machine executes.
Implementation and Agent QA are automated. Your team's energy shifts to ideation and time-to-market, not top-down execution.
Maintainable code
Conventions enforced. House skills. Living docs. Built to stay maintainable in year two.
Architected, not improvised
Modules first, code second. Senior engineers design boundaries before AI writes a line.
Tested, with evidence
Every AC verified on a real browser. Regression suite as a gate. Failed = blocked.
Senior teams, not AI slop
Every line reviewed by an engineer who has shipped fintech-grade systems before.
Illustrative example: fictional client FinCo. Figures are not S-PRO results or prices.
Need subscription & payments on the platform
Hi S-PRO team,
Quick one. I want to add subscription and payments to my platform. Users are growing and we need to start charging by Q3.
How fast can we turn this around?
Best,
John
CEO · FinCo
Re: Need subscription & payments on the platform
Hi John,
We will confirm the plan once the spec is reviewed.
Best,
Sarah
Product Owner · S-PRO
What does the AI-enhanced SDLC look like step by step?
Seven steps take a business case to a tested feature. Claude does the preparation, drafting and checking; engineers review the results, with a four-eyes merge request review and a security checklist.
- Turn the business case into stories. Epics and stories are written in Jira, built on previous projects and Confluence documentation.
- Agentic prototyping. Claude builds a working prototype from the stories for early feedback.
- Create the architecture. Claude reads the tokenised Figma design layer and writes the architecture to Confluence.
- Finalise the architecture. Prototype learnings and architecture come together in one agreed target design.
- Implement the feature. Backend and frontend are built in parallel waves, with one stacked merge request per wave.
- Review the code. Every merge request is checked against project standards the moment it opens, with a four-eyes review and a security checklist.
- Agentic QA. AI tests each feature in a real browser, files bugs to Jira and reports with screenshots.
The flow is built from Claude skills that read from or write to the team's tools through MCP: Jira and Confluence for stories, tasks and architecture; a knowledge graph of previous projects; the IDE for implementation; GitHub Actions for the CI/CD pipeline; Playwright in a real browser for QA. The tool set depends on the final tech stack of each client.
How does S-PRO automate the software lifecycle for banks?
AI SDLC automation is part of S-PRO Agents, S-PRO's own agentic platform: the core of our products and of the solutions we build for clients. Around the platform we build the client's solution and deliver it as a service. For banks and financial institutions this means AI agents work across specification, development, infrastructure, QA and operations inside the client's own tools, and every change passes human review and the client's quality gates before release. S-PRO Agents also powers RegRadar (regulatory change monitoring) and Microsoft Copilot Booster (an agents hub that connects to Microsoft Copilot). S-PRO is a Certified partner in the Claude Partner Network, and our team includes Claude-certified engineers and architects.
See also: AI agents for banks, AI pilot to production, fintech software development.
Focus on your business. We take care of the product.
Experienced Product Owners, Business Analysts, and engineers run the build, backed by proven CI/CD, battle-tested infrastructure templates, and AI used where it actually helps. The spec, story tree, and wireframes are created directly in your tools, ready for your team's review. You stay close to your customers; we ship the software.
Not "what do you want?" Here's what works.
We don't open with a 40-page intake form. The client's wish lands; our senior Product Owner and BA reply with a concrete shape, drawn from every comparable service we've shipped. Recommendations, not interrogation.
For a service like yours, we recommend:
- ✓3 plan tiers with monthly/annual toggle and a featured plan.
- ✓14-day trial, no card upfront. Payment collected on day 12.
- ✓Stripe-hosted checkout for PCI SAQ-A scope. (Adyen if you need SEPA / iDEAL.)
- ✓Dunning sequence: 3 retries over 7 days, email at each step, then downgrade.
- ✓VAT per jurisdiction (CH, EU, US) on invoice. Multi-currency display.
- ✓Admin override, 30-day refund, full audit log.
Same source, decomposed into a feature tree.
The advice above wasn't invented. It came from the project's own sources: Confluence specs, Jira tickets, GitLab history, retrospectives. The same sources decompose the epic into a clean feature tree, each feature ready for stories.
Spec arrives in a shape you can review in five minutes.
Drafted from the BA conversation and grounded in the RAG context. Acceptance criteria are checkable. Edge cases that bit us before are already in here. You sign off, or send it back with one comment.
Subscribe to a plan and start a paid trial
As a registered user on the platform,
I want to choose a subscription plan and start a 14-day free trial without entering payment details upfront,
So that I can evaluate the paid features risk-free before committing.
- ✓User sees three plans (Starter, Pro, Business) with pricing in the user's currency, monthly/annual toggle, and a clearly featured plan.
- ✓Selecting a plan starts a trial immediately; payment details are collected on day 12 via a Stripe-hosted page (PCI SAQ-A scope).
- ✓If payment fails on first charge, dunning runs for 7 days (3 retries) before access downgrades. User notified by email at each step.
- ✓VAT calculated by jurisdiction (CH, EU, US) and shown on invoice; invoices stored in Confluence-linked archive bucket.
- ✓Admin can override plan, extend trial, or refund within 30 days from the back-office (audit-logged).
Best-in-class flows, not invented from scratch.
Our designer ideates with Claude using the project's existing Figma design system, then cross-references real-world flows from Mobbin (Airbnb, Duolingo, Stripe, Netflix). The result: subscription and checkout flows that feel native to the product and follow patterns users already understand.
Claude
Generates first-draft layouts, micro-copy, and component variants, applying the project's existing design tokens automatically.
Mobbin
Real flows from successful apps: Stripe Checkout, Netflix plan switcher, Spotify upgrade. We compare ours to theirs before we ship.
Figma
Our pre-built design system. The same tokens, components, and primitives the rest of the product is built on, so new screens look like they belong.
Spec, design, and tickets, landed in your tools.
The deliverables don't live in any AI tool. They land where your team already works: Confluence for the spec, Jira for the backlog, Figma for the UI. Engineering starts from a reviewed, linked backlog.
Business context, BA Q&A, decisions, RAG references. Living document.
Story tree with acceptance criteria, estimates, and prioritisation. Backlog-ready.
Plan selection, checkout, success, billing back-office. All on the design system.
Tickets land in the IDE. Engineers ship.
The work doesn't move into a different tool. It comes to where the engineer already is. Claude pulls the ticket and the Confluence spec into the IDE via MCP, the work splits into backend and frontend tracks, and our in-house Claude skills handle the patterns we've seen ship a hundred times before.
AI that respects your codebase.
Before Claude writes a line of payment code, it loads FinCo's project contract: file structure, naming conventions, scope of changes for this sprint, what's out of bounds. The SubscriptionController that lands in the PR feels like FinCo's existing services. Same patterns, same boundaries, same vocabulary. No drive-by refactors. No convention violations. No "AI doing AI things."
›load project rulebook for finco-platform
Claude MCP brings everything in.
The engineer doesn't switch tabs. Claude pulls PAY-101 from Jira, the spec from Confluence, and the most relevant prior implementations from our RAG knowledge base, all into the editor in seconds.
›pull PAY-101 with spec and prior art
Backend and frontend in parallel.
The same loaded context fans out to two engineers. Each gets the slice of work relevant to their stack, plus a curated set of in-house Claude skills, refined over years of S-PRO projects.
Subscription & billing services
Senior backend engineer designs the module architecture first (services, adapters, workers), then implements within those modules using house Claude skills.
Plan selection & checkout UI
Designs come from Figma via MCP. The engineer's job is to validate the generated components, wire them to the API, and handle accessibility & states.
Modules before code.
The senior backend engineer designs the module boundaries first: what's a service, what's a worker, what's an adapter. Once the architecture is reviewed, house Claude skills generate the boilerplate within each module's contract.
Backend ships an endpoint. Frontend Claude sees it from the shared contract.
The moment the SubscriptionController lands POST /subscriptions and
POST /subscriptions/:id/cancel, the API contract auto-syncs into the
frontend repo. Next time the frontend engineer opens Claude, the new endpoints are
already in context. No stale Postman collection. No Slack ping asking about the
request body. Frontend wires up the API from the shared contract as soon as backend publishes it.
Designs flow into code, not get rebuilt.
The Figma frame is the source of truth. A Figma MCP server reads the design, and house Claude skills generate a React component using our existing design tokens. The engineer's job: validate, wire to the API, and ship.
export const PlanSelector = ({ plans, onSelect }) => { const [billing, setBilling] = useState('monthly'); return ( <Stack tokens={tokens.plans}> <BillingToggle value={billing} onChange={setBilling} /> {plans.map(p => ( <PlanCard key={p.id} plan={p} featured={p.featured} onPick={onSelect} /> ))} <Button variant="primary"> Start 14-day free trial </Button> </Stack> ); };
From feature to cloud topology, in one prompt.
The payments-service needs more than code. It needs a database, a queue, secrets, a webhook endpoint, observability, and somewhere to actually run. Claude drafts the Infrastructure-as-Code from patterns we've shipped before across AWS, Azure, and GCP, generating Terraform, Pulumi, or CDK as appropriate. The engineer reviews, hardens, and applies.
Resources first, code second.
Pulling from past Subscription & Payments deployments, Claude proposes the resource set: edge, compute, data, secrets, observability, integrations. The engineer prunes what isn't needed for this client (no Redis if the existing app already has one) and adds anything specific.
Terraform for the cloud, Helm for the cluster.
Same approach as the backend code: house Claude skills generate first-draft Terraform modules and Helm values. The engineer reads every line, hardens IAM and network rules, and applies. Nothing is autonomous: every infrastructure change is reviewed by an engineer.
# Subscription & Payments stack module "payments_db" { source = "./modules/rds-postgres" name = "subscriptions" instance_class = "db.t4g.small" multi_az = var.env == "prod" } module "payments_service" { source = "./modules/ecs-service" name = "payments-service" cpu = 512 memory = 1024 desired_count = var.env == "prod" ? 3 : 1 secrets = [ "stripe/secret_key", "stripe/webhook_secret", ] } module "webhook_endpoint" { source = "./modules/stripe-webhook" events = [ "invoice.payment_failed", "customer.subscription.updated", ] }
replicaCount: {{ .Values.env.replicas }} image: repository: payments-service tag: {{ .Chart.AppVersion }} resources: requests: cpu: 200m memory: 512Mi limits: cpu: 500m memory: 1Gi autoscaling: enabled: true minReplicas: 2 maxReplicas: 10 targetCPU: 70 env: - name: DATABASE_URL valueFrom: secretKeyRef: payments-db
Dev to prod with the same source of truth.
The same Terraform and Helm modules apply across dev, staging, and production. Differences are environment-scoped variables (instance sizes, replica counts, retention windows), not hand-edited overrides. Drift is checked nightly.
Development
SyncedStaging
SyncedProduction
SyncedQA without the bottleneck.
Our Agent QA pulls QA-ready tickets from Jira, drafts test scenarios from the acceptance criteria, and Playwright MCP clicks through them on real browsers. Same scenarios run as nightly regression. The output is a test report with evidence, not a green check from a black box.
Claude lists the ready tickets first.
QA doesn't chase tickets. Claude reads Jira and groups everything by status — what dev says is ready, what's in progress, what's blocked — so the tester sees the whole batch at once.
›what's ready for QA on the Subscription & Payments epic?
No fragile selectors. No page objects.
For each acceptance criterion, Claude drafts a numbered scenario any tester (or any client stakeholder) can read. The QA engineer reviews, edits, and hands it to Playwright MCP to run.
- Log in as the test user
alice@finco.ch(no active subscription). - Navigate to
/pricing. - Click Start trial on the Pro plan card.
- Verify the page redirects to
/dashboard/pro. - Verify the trial banner reads "14 days remaining".
- Verify no payment page is shown on first entry.
- Advance the clock by 11 days via
scheduler.advance(11d). - Verify the user receives the add-payment-method email.
- Verify
/billingshows the "Add payment method" CTA.
Playwright MCP runs the scenario.
Claude drives Chromium step by step, reads the live DOM (not just pixels), takes screenshots on failure, and re-runs after fixes. The same scenarios run nightly as full regression — anything that breaks gets a report waiting on the team's Slack before standup.
- ✓Logged in as
alice@finco.ch - ✓Navigated to
/pricing - ✓Clicked Start trial on Pro plan card
- ✓Redirected to
/dashboard/pro - ▶Verifying trial banner shows 14 days remaining…
- ○Verify no payment page on first entry
- ○Advance clock
scheduler.advance(11d) - ○Verify add-payment-method email sent
Two roles, one regression pass.
PAY-101 has two roles in play: the customer subscribing to a plan and the admin in the back-office overriding plans, extending trials, and refunding charges. Both flows run in parallel inside a single browser window with cookies, sessions, and storage isolated per tab. One regression pass verifies the customer subscribed, the admin saw the audit-log entry land, and the override applied, with zero cross-contamination between the sessions.
A signed-off report, not a green check.
Every QA pass produces a report you can audit: which AC was checked, with what steps, with what result. Failures include the exact reproduction trail and a one-click Copy bug to drop straight into Jira.
Test Report: PAY-101 · Subscribe to a plan
Summary
Test Coverage Matrix
| Area | AC | Passed | Failed | Blocked | Coverage |
|---|---|---|---|---|---|
| Plan selection & pricing | AC-001 | 1 | 0 | 0 | 100% |
| Trial start without payment | AC-002 | 1 | 0 | 0 | 100% |
| Failed-payment dunning | AC-003 | 0 | 1 | 0 | 0% |
| VAT calculation by jurisdiction | AC-004 | 1 | 0 | 0 | 100% |
| Admin override & refund | AC-005 | 1 | 0 | 0 | 100% |
| Total | 5 | 4 | 1 | 0 | 80% |
Failed (1 / 5)
From AC: "If payment fails on first charge, dunning runs for 7 days (3 retries) before access downgrades. User notified by email at each step."
- Set up subscription with Stripe failing test card
4000 0000 0000 0341 - Triggered first charge attempt at 09:00 via webhook simulator
- Waited for first retry at 09:15
- FAIL — No dunning email received until 2nd retry at 09:30
- Expected: email after first failure. Actual: only after second.
The whole suite, one button, anyone on the team.
Once PAY-101's scenarios pass, they're registered in the project's test management system: version-controlled, tagged, linked to acceptance criteria. When PAY-102 ships, the same suite runs as the gate. When FinCo onboards a new QA, that QA can run the existing regression suite straight away. Claude can run the suite too, no human required for "is the subscription flow still green?"
Regression isn't a person. It's a button.Release candidate, retrospective, knowledge loop closed.
PAY-101 doesn't end at "merged". The release ships, the system observes, the team learns, and the next epic starts with what we just learned baked in.
Read the PRs. Write the notes. Sign off.
Claude reads the PAY-101 PRs and the linked Jira tickets, then drafts release notes in FinCo's house format: customer-facing changelog, internal API diff, migration notes for the platform team. Engineering signs off; nothing is hand-typed twice.
Release notes · PAY-101 ships
- NEW14-day free trial on Pro and Business plans, no card upfront.
- NEWStripe-hosted payment collection on day 12 of the trial.
- IMPRMulti-currency display on the plan selector (CHF, EUR, USD).
- +
POST /api/v1/subscriptions - +
POST /api/v1/subscriptions/:id/cancel - ~
GET /api/v1/billing/invoicesnow returns VAT.
- ENVNew:
STRIPE_API_KEY,STRIPE_WEBHOOK_SECRETin Secrets Manager. - SQLMigration
2026_05_07_subscriptions_init.sqlapplied.
Reviewed by SRE before the first incident.
Stripe webhook stalls. Dunning queue backed up. VAT API rate-limited. Failed invoice generation. Each scenario gets a runbook generated from the architecture diagram: recovery path, on-call escalation, rollback trigger.
Behind a flag, on a slice of traffic.
PAY-101 ships behind a feature flag, canary'd to a slice of FinCo's traffic. Metrics on subscription-success, dunning-trigger, and VAT-calculation are wired in before deploy. Anomaly thresholds are tuned against real usage after release.
PAY-102 starts with PAY-101's lessons loaded.
What worked, what slipped, what surprised us. Captured and indexed back into the knowledge base. The next epic on this product (or a comparable one) starts smarter, automatically.
- Figma MCP sped up the plan selector.
- RAG context on AC-002 caught the trial-edge bug pre-merge.
- House
stripe-checkoutskill: zero rework.
- Dunning email timing (AC-003): caught in QA, not unit.
- Adyen credentials delayed PAY-112.
- VAT for CH was simpler than expected (single rate).
- Multi-currency display worked as planned.
Scheduled audits keep the codebase healthy after release.
After PAY-101 ships, the AI agent runs the project's first scheduled tech audit on the new code: architecture drift, unused exports, dead branches in the dunning logic, dependencies that fell behind. From here, the audit runs on a schedule across the whole codebase; the cadence is agreed per project.
PAY-101 · 14 days post-release
- 0 architecture drift against the rulebook OK
-
2
unused exports in
subscription.service.tsLow - 1 dead branch in dunning retry logic Low
-
3
dependencies behind:
stripe,zod,pgMedium
Where do we already use Claude Code in delivery?
Two product teams use Claude Code in development.
- Finka. The team uses Claude Code in the development of the Finka platform for digital metals concentrate trading. It sped up development; we do not state a percentage.
- Muuvr. The team uses Claude Code with Figma MCP to assemble screens from existing components and build mobile features. Working screens appear in the emulator during joint sessions. Estimated by the team: about 50% shorter cycle for validating interface ideas and 30–40% higher development productivity. See the Muuvr case.
The Muuvr figures are estimates by the team, not measured benchmarks. Our team includes Claude-certified engineers and architects.
Things we get asked.
Real questions from real prospects, answered straight.
While AI coding assistants are incredible tools, they are not magic wands for complex software. When you scale beyond a simple prototype, AI quickly hits context limits, struggles with complex integrations, and gets confused managing dozens of concurrent tickets.
We bring the engineering mindset required to manage context windows, token optimization, and system architecture so your project actually crosses the finish line.
Yes, it is secure. We use enterprise-grade environments and strict data governance policies. Client data is processed under the contract and under the controls of our ISO 27001 / ISO 27701 certifications.
We ensure that your intellectual property remains entirely yours and completely isolated.
Absolutely. Our AI SDLC methodology is completely model-agnostic.
If your compliance team restricts the use of tools like Claude or OpenAI, we can route your development through secure, approved enterprise foundries or private cloud environments like AWS Bedrock or MS Foundry.
No. There is a massive difference between fast "AI slop" and our banking-grade methodology. We don't just let AI write code unchecked; we use AI to enhance the workflows of senior engineers.
Every line of code goes through rigorous Agent QA and automated testing (like Playwright) to ensure the architecture is solid, scalable, and maintainable.
Unmanaged AI development can quickly snowball in cost due to poor "tokenomics". Our architects structure prompts and context sharing to heavily optimize token usage.
We know exactly how to leverage the technology efficiently so token costs stay under control without sacrificing quality.
The AI landscape changes quickly, so we keep our process under review. We continuously benchmark, test, and integrate the latest state-of-the-art models and tools into our pipeline.
Our landing page reflects our current stack, and we transparently review and update our methodology regularly to ensure you are always getting the most competitive edge possible.
Not at all. Our approach automates the tedious execution and validation phases, which frees up our senior engineers and product owners to act as true consultants.
By letting AI handle the heavy lifting of code generation, our human engineers focus entirely on your business logic, creative problem-solving, and ensuring the product perfectly matches your vision.
AI agents take over specification drafting, boilerplate, test generation and documentation, so engineers spend more time on review and design.
Delivery time depends on scope and is estimated after discovery. Review and testing stay in place, so products reach your users sooner without dropping the quality gates.
It is a delivery process where AI agents handle repeatable work across the software lifecycle (specification drafts, code scaffolding, test generation, documentation, scheduled technical audits) while engineers and the bank's own reviewers approve every change. S-PRO runs it on S-PRO Agents, our own agentic platform, inside the client's tools and controls.
No. Agents prepare and check work; people review and approve. Nothing is released autonomously, and the client's security, change-management and regulatory processes stay in place. Timelines and effort depend on scope and are estimated after discovery.
Seven steps: turn the business case into Jira stories, build an agentic prototype, create the architecture from the Figma design layer, finalise it, implement backend and frontend in parallel waves, review every merge request against project standards, and run agentic QA in a real browser. Merge requests get a four-eyes review and a security checklist.
Teams that use it report gains. On Muuvr, the team estimates a cycle for validating interface ideas about 50% shorter and 30–40% higher development productivity; these are estimates by the team. On Finka, Claude Code sped up development and we do not claim a percentage.