chore: update v3 OpenAPI specs to v3.845.0

[Ed Fricker (beastawakens)]

User description

Automated v3 OpenAPI spec update for v3.845.0.

Triggered by Solomon Nsubuga (@solnsubuga) - assigned to you in case it needs a manual merge.

---

PR Type

Enhancement, Documentation

---

Description

• Add new POST /v3/aml/monitoring spec and endpoint

• Replace AML adverse_media with news_summary

• Rename reason adverse_media_match to news_media_match

• Update docs, README table, and CHANGELOG for v3.845.0

---

Diagram Walkthrough

flowchart LR
  A["v3.845.0 spec sync"] -- "new spec" --> B["v3-aml-monitoring-entry.yaml"]
  A -- "aggregate spec" --> C["openapi.yaml: /v3/aml/monitoring + AmlMonitoringRequest"]
  A -- "AML field rework" --> D["adverse_media -> news_summary"]
  D -- "reason enum" --> E["news_media_match"]
  A -- "listings" --> F["README + docs/index.html"]
  A -- "release notes" --> G["CHANGELOG.md"]

Loading

File Walkthrough

	Relevant files
Enhancement	v3-aml-monitoring-entry.yaml New AML Monitoring endpoint specification                                specs/v3/v3-aml-monitoring-entry.yaml New standalone spec for POST /v3/aml/monitoring (async AML monitoring enrollment). Defines AmlMonitoringRequest (countries, full_name, birth_year, aliases, strict_match, search_existing_user, user_details, consent, callback_url). Documents multipart/form-data JSON-encoded array fields and SmileID auth/HMAC headers. Adds 202/400/401/402/403/404/415/429/500 responses with examples plus Consent, AcceptedResponse, ApiErrorResponse schemas. +459/-0  openapi.yaml Aggregate spec: add AML Monitoring, rework news media        specs/v3/openapi.yaml Adds AML Monitoring tag and /v3/aml/monitoring POST operation with full response set. Adds AmlMonitoringRequest schema and reorders BiometricAuthenticationRequest definition. Replaces AML adverse_media array with structured news_summary (category, label, article count). Renames reason enum/examples from adverse_media_match to news_media_match. +416/-57 v3-one-time-aml-entry.yaml One-Time AML: news_summary replaces adverse_media                specs/v3/v3-one-time-aml-entry.yaml Replaces adverse_media field with news_summary object array in person schema. Updates callback/response examples to news media wording and structure. Updates reason enum to news_media_match. +30/-17
Documentation	index.html Register AML Monitoring spec in docs viewer                            docs/index.html Adds v3-aml-monitoring-entry entry to the docs spec selector list. +1/-0      README.md Document AML Monitoring spec in README table                          README.md Adds AML Monitoring row to the spec table with endpoint and description. +1/-0      CHANGELOG.md Add v3.845.0 changelog entry                                                          CHANGELOG.md Adds v3.845.0 release entry dated 2026-08-21. Lists updates to openapi, v3-aml-monitoring-entry, and v3-one-time-aml-entry. +8/-0

---

---

Need help?

Type /help how to ... in the comments thread for any questions about PR-Agent usage.

Check out the documentation for more information.

[prfectionist]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🏅 Score: 78

🧪 No relevant tests

🔒 No security concerns identified

🔀 No multiple PR themes

⚡ Recommended focus areas for review Schema/Encoding Mismatch The request body prose instructs clients to send countries and aliases as a single JSON-encoded string, but the schema declares them as type: array in a multipart/form-data body with no encoding section. Per OpenAPI defaults, array-of-string properties in multipart are serialized as repeated form parts, so generated SDKs and request validators will produce exactly the repeated-field form the description says will fail validation. Either declare an encoding entry with contentType: application/json for these properties, or model them as type: string with a JSON-array pattern/description. The same schema in specs/v3/openapi.yaml has the identical problem. requestBody: required: true description: >- multipart/form-data. Array fields (`countries`, `aliases`) must be sent as a single JSON-encoded string (e.g. `countries='["NG","GH"]'`), not as repeated form fields — multipart has no array encoding and a repeated field is overwritten, which fails validation. content: multipart/form-data: schema: $ref: '#/components/schemas/AmlMonitoringRequest' Validation Gap The conditional requirements for AML monitoring are documented only in prose: full_name is required unless search_existing_user is true, and user_id is required in the body when search_existing_user is true. The schema's required list only contains countries, user_details, and consent, so a request with none of full_name, search_existing_user, or user_id validates as correct against the spec but is rejected with 400 by the API. Other request schemas in this repo (e.g. BiometricAuthenticationRequest) express such constraints with anyOf/required combinations; doing the same here would keep clients and mock validators in sync. AmlMonitoringRequest: type: object required: - countries - user_details - consent properties: countries: type: array minItems: 1 description: >- ISO 3166-1 alpha-2 country codes (uppercase) to screen against. Send as a JSON-encoded string in the multipart body, e.g. '["NG","GH"]'. items: type: string minLength: 2 maxLength: 2 example: NG full_name: type: string minLength: 1 description: >- Full name of the individual to screen. Required unless `search_existing_user` is true, in which case the name is resolved from the user's prior KYC enrollment. example: Jane Doe birth_year: type: string pattern: '^\d{4}$' nullable: true description: Optional four-digit birth year used to narrow the screening. example: '1990' strict_match: type: boolean default: true description: >- When true (default) a higher match threshold is used, returning fewer, more precise matches. When false a broader threshold is used. example: true aliases: type: array maxItems: 20 description: >- Optional alternate names / spellings to screen alongside full_name. Send as a JSON-encoded string in the multipart body, e.g. '["Jane A. Doe","J. Doe"]'. items: type: string minLength: 1 maxLength: 256 example: J. Doe search_existing_user: type: boolean description: >- When set, reuses the name (and birth year) from the user's prior Biometric KYC or Document Verification enrollment. Requires `user_id` (or the User-ID header), and that user must be an enrollee of this partner with a prior KYC record carrying a usable name and country — otherwise the request is rejected with a 404. example: false user_id: type: string description: >- Partner-provided user identifier. Optional, but required in the body when `search_existing_user` is true; the User-ID header and token only have to agree with it. example: user_01h8x9y2z3a4b5c6d7e8f9g0h1

[prfectionist]

Suggestion: The requestBody description states that countries and aliases must be sent as a single JSON-encoded string, but the schema declares them as plain arrays, so generated clients will emit repeated form fields and the request will fail validation. Declare an encoding block marking these parts as application/json so tooling/codegen serializes them correctly. [possible issue, importance: 6]

Suggested change

	content:
	multipart/form-data:
	schema:
	$ref: '#/components/schemas/AmlMonitoringRequest'
	content:
	multipart/form-data:
	schema:
	$ref: '#/components/schemas/AmlMonitoringRequest'
	encoding:
	countries:
	contentType: application/json
	aliases:
	contentType: application/json

[prfectionist]

Suggestion: The documented rule "full_name is required unless search_existing_user is true" is not expressed in the schema, so invalid payloads (neither field present) validate successfully and only fail server-side with a 400. Encode the constraint with anyOf, mirroring the pattern already used by BiometricAuthenticationRequest. [general, importance: 5]

Suggested change

	AmlMonitoringRequest:
	type: object
	required:
	- countries
	- user_details
	- consent
	properties:
	AmlMonitoringRequest:
	type: object
	required:
	- countries
	- user_details
	- consent
	anyOf:
	- required:
	- full_name
	- required:
	- search_existing_user
	properties:
	search_existing_user:
	type: boolean
	enum:
	- true
	properties:

[prfectionist]

Suggestion: countries items only constrain length, so lowercase or non-alphabetic values like ng or 12 validate but will be rejected by the API. Add the uppercase alpha-2 pattern (consistent with the existing country query parameter) so client-side validation matches server behaviour. [general, importance: 5]

Suggested change

	countries:
	type: array
	minItems: 1
	description: >-
	ISO 3166-1 alpha-2 country codes (uppercase) to screen against. Send
	as a JSON-encoded string in the multipart body, e.g. '["NG","GH"]'.
	items:
	type: string
	minLength: 2
	maxLength: 2
	example: NG
	countries:
	type: array
	minItems: 1
	description: >-
	ISO 3166-1 alpha-2 country codes (uppercase) to screen against. Send
	as a JSON-encoded string in the multipart body, e.g. '["NG","GH"]'.
	items:
	type: string
	minLength: 2
	maxLength: 2
	pattern: '^[A-Z]{2}$'
	example: NG