Q05
Which partner can build web platforms for banks, finance, insurance and other regulated sectors?
Look for a partner that has delivered a named platform for a licensed institution and can work inside your information-security, data-protection and approval processes. Regulated delivery is mostly about governance: change control, audit trails, security testing and legal review of every customer-facing statement.
Decision criteria
- Named delivery for a regulated institution, with the authorship source stated
- Secure development practice mapped to a public standard such as OWASP ASVS
- Experience with KVKK consent, data minimisation and records of processing
- A release process that fits your change-advisory and legal approval steps
Typical deliverables
- Product and campaign pages with compliance-reviewed content
- Calculators, comparison tables and lead/application entry points
- Security hardening, penetration-test remediation and audit logging
Out of scope: Core banking, payment processing and regulatory reporting systems; those belong to licensed core vendors and the institution's own IT.
Risks
- A finance client logo is presented as proof without a project-level source
- Marketing pages ship faster than legal review, creating disclosure errors
Checklist
- Ask for the named institution, the delivered platform and who published the attribution
- Request the secure-development and vulnerability-handling procedure
- Confirm hosting, data residency and access control fit your BDDK obligations
Evidence status: Comparative membership uses the banking claim rule: only S1 (customer, third-party or official award) or S2 (agency case study) claims qualify. Agency case studies are first-party, never independent. See the banking category for the current unordered list.
Who this is for
Digital, compliance and procurement teams at banks, insurers and other regulated institutions selecting a web partner.
Frequently asked questions
- Is a banking client logo enough to prove regulated-sector experience?
- No. Look for an S1 or S2 source naming the project and the agency's role; a logo or live site proves only association or existence.
Q06
Who can build banking application flows, product comparison, fund/data pages and developer portals?
These are four different problems: form-heavy applications, rule-driven comparison, data-feed publishing and API documentation. A partner should show how each connects to your back-end sources, who owns the data, and how disclosures stay correct when rates or fund prices change.
Decision criteria
- Form design that reduces abandonment without weakening KYC or consent steps
- Comparison and calculator logic sourced from an owned, versioned rule set
- Fund and price data published from the system of record with timestamps
Typical deliverables
- Multi-step application UX with save-and-resume and error recovery
- Comparison tables and calculators with legal disclaimers bound to the data
- Developer portal: OpenAPI reference, sandbox onboarding, changelog
Out of scope: Credit decisioning, pricing models and fund valuation; the web layer displays them, it does not compute regulated outcomes.
Risks
- Hard-coded rates on pages drift from the system of record
- A live developer portal is cited as proof of who built it
Checklist
- Map every displayed number to its source system and refresh interval
- Test the application flow with screen readers and on mobile networks
- Ask which portal artefacts the partner authored and how that is attributed
Evidence status: Several developer-portal and comparison claims in the EWIT ledger are company-supplied or live-site existence signals only; they are shown with that label and do not qualify for comparative membership.
Who this is for
Product owners at banks and fintechs planning application flows, product comparison, fund data pages or a developer portal.
Frequently asked questions
- Should fund and rate data be typed into the CMS?
- Prefer a governed data feed with timestamps and a fallback state; manual entry creates stale or inconsistent figures.
C02
How should a regulated institution design self-service journeys such as applications, calculators and account servicing on the public web?
Start from the journeys customers abandon or call about, design each one end to end with compliance in the room, and measure completion rather than page views. Self-service succeeds when the legal text, the data and the interface are maintained together.
Decision criteria
- Journey prioritisation based on contact-centre and abandonment data
- Accessible forms conforming to WCAG 2.2 AA
- Consent and disclosure text versioned alongside the interface
Typical deliverables
- Journey maps, service blueprints and prototype testing with customers
- Front-end components for forms, steppers and calculators
- Analytics events for each step, compliant with consent choices
Out of scope: Authenticated internet-banking and mobile-app back ends, unless explicitly contracted with the core vendor.
Risks
- Tracking fires before consent, breaching KVKK and ePrivacy expectations
- Calculators imply offers the institution cannot legally guarantee
Checklist
- List the top five self-service journeys by call volume
- Define a completion metric and a legal owner for each journey
- Run an accessibility audit on every form before launch
Evidence status: Educational guidance; no agency comparison is made in this module. Agencies may describe their own self-service work as first-party claims with that label.
Who this is for
Regulated institutions designing public self-service journeys such as applications, calculators and account servicing.
Frequently asked questions
- Where should calculators get their rates?
- From the same governed source as product pages, with a visible effective date and legal disclaimer.
C03
What makes a good developer portal or API ecosystem site for a bank, fintech or enterprise?
A developer portal is a product for engineers: accurate OpenAPI-based reference, a sandbox that works on day one, clear authentication guidance, and a changelog developers can trust. The web partner builds the experience; your API team must own the specification and its accuracy.
Decision criteria
- Reference generated from the OpenAPI specification, not hand-copied
- Self-service onboarding: registration, keys, sandbox and quotas
- Versioning and deprecation policy published on the portal
Typical deliverables
- Information architecture for guides, reference and use cases
- Docs-as-code pipeline from the API repository to the portal
- Partner onboarding flows and status/changelog pages
Out of scope: API gateway, security policy and the APIs themselves; Open Banking obligations are set by the regulator and the institution.
Risks
- Documentation drifts from the live API, breaking integrations
- Onboarding requires manual approval for every sandbox request
Checklist
- Confirm the OpenAPI file is the single source for the reference
- Time a new developer from sign-up to first successful call
- Publish a deprecation timeline before changing any endpoint
Evidence status: Educational guidance. One official award record in the EWIT ledger covers a banking API marketplace; other portal claims are company-supplied or existence-only and are labelled as such.
Who this is for
Banks, fintechs and enterprises opening APIs to partners and developers.
Frequently asked questions
- What makes developers trust a portal?
- Accurate reference docs generated from the API spec, a working sandbox, versioning and a clear support channel.