As others have said, never map business value to HTTP response codes. Each response code is described by a specification and MUST be used for the specified reason ONLY. If the error does not fit into one of the buckets, then use 400 or 500 with an error body.

The general guidance is that clients SHOULD NOT retry 4xx status codes without modifying the request and clients MAY retry 5xx status codes. There are some exceptions (429 I’m looking at you). In both cases, the server MAY include additional guidance as headers (e.g., Retry-After) as well as in the content body.

RFC-7231 includes the following text in the introduction to both the 400 and 500 family of status codes.

Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition.

With all of that being said, well-written APIs do what makes sense. I have trouble envisioning using HTTP status codes for anything outside of the designated purpose. At the same time, I have a hearty dislike of HTTP APIs that return a 200 with an error body even though I understand the desire to separate application errors from protocol errors. A large part of a RESTful API in my opinion is breaking the application/protocol view and embrace using the protocol as part of the application.